On 22/03/2008, Phil Steitz <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >
+1 to all of the above. > Phil > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
