commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <>
Subject Re: [m2][PROPOSAL] Release process
Date Sat, 22 Mar 2008 23:26:58 GMT
On Sat, Mar 22, 2008 at 10:10 PM, Phil Steitz <> wrote:
> 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

Shouldn't that be "Iterate 1), 2), 3)" - i.e. tag for each RC?

>  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.

Since version 9  of commons-parent you can just do "mvn -Prc package"
- the "site" and "assembly" goals are run as part of the package phase
for the "rc" profile. My variation is I do  "mvn -Prc install" -
because it creates the md5/sha1 checksums and signatures as well (the
only downside is the you have to go to your local repo to find the

>  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.

+1, I haven't been doing your RC bit - all the RC's have the proper
version number. I guess I'm always optimistic that the 1st RC is going
to succeed :)

>  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

I think that should be *only release jars, the pom and their

>  6) All ASF release requirements regarding sigs, licenses, notices,
>  etc., must be satisfied

At some point I think we should add "releases are built with m2" to
the above list of requirements. Besides m1 becoming more obsolete, I
think making releases "OSGi ready" (which the m2 build does) tips the
balance. I guess the question is are people happy to make that
official policy now or are there objections?


>  Phil

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

View raw message