On 25 June 2013 20:15, 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.
Since the release process uses the revision number, it does not particularly matter that the code is still in trunk; after all trunk and tags are just names. I find it easier to work with a named tag (perhaps because I am used to it), but so long as the SVN source is uniquely identified and used to compare against the source contents it does not matter what the name is. > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
