commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [m2][PROPOSAL] Release process
Date Sat, 22 Mar 2008 22:10:58 GMT
First, thanks for helping move this along, Rahul.  We need to at least
get the "releasing" docs updated.

On Fri, Mar 21, 2008 at 3:41 PM, Rahul Akolkar <> wrote:
> Based on couple of JIRA comments, it seems there still isn't consensus
>  about a release process using m2 at Commons. I'll try to outline the
>  process.
>  <outline>
>  [A] Release prep
>  [B] Stage artifacts and site, to some location TBD (entire commands
>  below, not abridged etc.):
>  mvn -Prc release:prepare
>  mvn -Prc release:perform
>  mvn -Prc site-deploy
>  Or, if you don't care about the release plugin, after setting final
>  versions in [A]:
>  mvn -Prc deploy
>  mvn -Prc site-deploy
>  [C] Vote
>  [D] Go live
>  mvn stage:copy ...
>  mvn site-deploy
>  </outline>
>  Does this fit your mental model? If not, why not?
>  Please keep the discussion at a "vision" level. Yes, the outline is
>  flawed (all votes don't pass, there are loops etc.) Yes, required pom
>  changes are not discussed. But, once process is OK'ed, we will make
>  the poms do the right thing :-)

Keeping things at the "vision" level, what I like to do is

1) Once release plan is complete, create an RC tag
2) Build an RC, consisting of source, binary distros, web site, etc.
I like initial RCs to have "RC" in artifact names.  Call me old
fashioned, but I really do not like to create jars with final release
names until I am pretty sure that is what is going to be released.
3) Announce availability of RC, publish RC-labeled jar to snapshot
repo and tarballs to ~psteitz
3.5) Iterate 2), 3) 2-3 times until the community is happy with the results
4) Roll a "final" RC based on a "last" RC tag with
destined-for-release bits in it (i.e. artifact names do not include
"RC") and kick off a VOTE.
5) When the VOTE succeeds, copy the final RC tag to the release tag
and move the *same signed voted bits* moved to the mirrors and rsynch
maven repo.

I don't know exactly what the release plugin does, but unless and
until it does exactly those steps, I will do them manually.  I have
been able to get the candidate tarballs built using
"mv -Prc site package assembly:assembly" Then I sign and move things.
This is not a big problem for me.  I don't mind grabbing the site from
the tarballs and staging it manually to my home.  This takes 20
seconds and ensures that what we are reviewing / voting on the right
content.  The only part that is ugly / painful is doing 5) for the m2
jar repos.  A simple way to do that without hacking the metadata or
having to regenerate the jars would be nice to have.

Things I like to avoid:
1) altering tags
2) producing artifacts with the same names, but different contents
(why I like to wait do do 4 until I am pretty certain the vote is
going to pass).
3) allowing tag - artifact correspondence to be broken (i.e.
one-to-one correspondence between immutable tags and artifacts, with
artifacts always reproducible from tags).

I don't think it is necessary for all commons release managers to use
the same automation.  We should try to make it as easy as possible for
people to cut releases that meet our requirements, but I think RMs
should have flexibility on what tools / approaches they want to use.
The only *requirements* that we have are

1) We vote on final bits - i.e. what goes out to the mirrors is
exactly what we VOTE on
2) Releases are (perpetually) reproducible from tags
3) Binaries must be buildable from source release packages
4) Release tars and zips must be published to the commons download site
5) Release jars - and *only release jars* - must be published to
apache m2 rsynch repo
6) All ASF release requirements regarding sigs, licenses, notices,
etc., must be satisfied


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message