commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [m2][PROPOSAL] Release process
Date Sun, 23 Mar 2008 04:05:35 GMT
On 3/22/08, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> On Sat, Mar 22, 2008 at 10:10 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
<snip/>
>  >
>  >  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.
>
>
> +1
>
>
>  > 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
>  checksums).
>
<snap/>

And the next step in that logical progression is "mvn -Prc deploy"
(variants in [B]) which posts everything to a remote staging
repository, ready for inspection by the greater community.

I tried this for a snapshot build a few days ago (works great,
thanks!), though I haven't inspected the artifacts myself yet:

  http://people.apache.org/repo/m2-snapshot-repository/commons-scxml/commons-scxml/0.8-SNAPSHOT/


>
>  >  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
>  signatures/checksums*.
>
>
>  >  6) All ASF release requirements regarding sigs, licenses, notices,
>  >  etc., must be satisfied
>
<snip/>

Indeed, we wouldn't settle for anything less, whatever the tools :-)
(WRT the 6 items above)


>
> 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?
>
<snap/>

While I agree that such policy will streamline much of the release
processes, I care more about the end effect than the means, which I'd
rather leave to the RM. I will continue to support releases cut using
m1 (or ant), as long as they meet the fundamental requirements for a
good release.

This discussion was initiated because unless most of us planning on
using m2 form a collective cutting releases process vision, we'll be
pulling the parent pom(s) in different directions.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message