On 3/22/08, Niall Pemberton <[EMAIL PROTECTED]> wrote: > On Sat, Mar 22, 2008 at 10:10 PM, Phil Steitz <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
