I very much prefer your method, Uwe! There are lots of ways to do this "right". I hope one of those is chosen.
On Tue, Jun 25, 2013 at 9:15 PM, Uwe Schindler <u...@thetaphi.de> wrote: > Hi, > > I agree with sebb. I am not a Maven committer, but the release revision is > very important in the Lucene Project (where I am the chair). > We have another workflow, working with revision number: > - Release manager produces source and binary artifacts from a checkout of > the current development brank (trunk aka 5.x or stable aka 4.x), publishes > them on people.apache.org in a folder named > http://people.apache.org/~use/staging-area/lucene-solr-X.Y-r1234567 > - Release manager does *not* create an SVN tag at that time!!! The vote is > on the revision and artifacts only! > - We have automated release testing (we check for spurious files in the > archives by our python-based "smoke tester"). This checks things like all > JARs have correct META-INF, no license files are missing, NOTICE files are > referring to *all* external dependencies, LICENSE.txt is in root folder of > TGZ, line feeds are unix-only, release binary was compiled with the > *minimum* JDK version (what we use as -source/-target for javac), and so on. > - Once vote passes, release manager tags the exact revision number as used > above in the folder name (svn cp -r1234567 ...) and releases the artifacts. > > By that there is no need to recreate tags, because the tag is only created > when the stuff was actually released. This is a slightly different > workflow, but is proven to work since years now. > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -----Original Message----- > > From: sebb [mailto:seb...@gmail.com] > > Sent: Tuesday, June 25, 2013 6:52 PM > > To: dev@maven.apache.org > > Subject: Release process updates > > > > The mission of the ASF is to release software as source, and to ensure > that > > the released source is available under the Apache Licence. > > > > Before a release can be approved it must be voted on by the PMC. > > The review process needs to establish that the proposed source release > > meets those aims. > > > > It's all but impossible for reviewers to examine every single file in a > source > > archive to determine if it meets the criteria. > > And it's not unknown for spurious files to creep into a release (perhaps > from > > a stale workspace - are releases always built from a fresh checkout of > the > > tag?) > > > > However, PMCs are also required to check what is added to the SCM > > (SVN/Git) to make sure it meets the required license criteria. > > This is done on an ongoing basis as part of reviewing check-ins and > accepting > > new contributions. > > So provided that all the files in the source release are also present in > SCM, > > the PMC can be reasonably sure that the source release meets the ASF > > criteria. > > > > Without having the SCM as a database of validated files, there are far > too > > many files in the average source archive to check individually. > > And how would one check their provenance? The obvious way is to compare > > them with the entries in SCM. > > > > Therefore, I contend that a release vote does not make sense without the > > SCM tag. > > In the case of SVN, since tags are not immutable, the vote e-mail also > needs > > the revision. > > > > Whether every reviewer actually checks the source archive against SCM is > > another matter. > > But if the required SCM information is not present, it would be > difficult to > > argue that the RM had provided sufficient information for a valid review > to > > take place. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional > > commands, e-mail: dev-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
