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 Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
