Hello Stefan, OK, maybe this does not comply with ASF procedures. I see that tomcat seems to be doing releases the same way as what you suggest and did for the antlib(s):
http://marc.theaimsgroup.com/?l=tomcat-dev&m=115859000312242&w=2 This procedure for releases opens for me a number of questions : - does it not force the project to actually hold two votes, one to choose a date to build a release candidate, the second to decide whether this release candidate is valid ? If you decide spontaneously to build a release candidate on a random date-time, chances are that it will not be accepted - should the release manager tag the code in any case before building ? Now there is a danger that you create a tag ANT_170 but then you get a negative vote, this is not 1.7.0 any more. Maybe the solution in this case is to remove the tag in subversion. Or can you create an interim tag called for instance ANT_170_build20061030123405 and rename the tag to something else if the corresponding build is accepted as a release - in the case of ant, the release manager must build with the assumption that the artefacts are going to be accepted as version x.y.z. The version is in defaultManifest.mf, in version.txt, in the naming of the artifacts. - since we will be releasing both to the maven directory tree and using our usual distribution system, does the release manager also need to upload the java-repository directory tree, maybe as a zip file ? - this procedure makes lose the time of the vote on the binary artifacts, where the release could actually already be made available - there is no clear calendar. I find it better if a project commits itself to some clear milestones If you say this system of creating a release candidate, uploading it to ~release_manager/betadistribution, then voting on accepting this as version xyz is ASF procedure, then I will have to live with it. But I will work to get the procedure changed towards more automation and more predictability. Regards, Antoine Stefan Bodewig wrote: > On Fri, 27 Oct 2006, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote: > > >> I prefer the procedure which I have used for Ant 1.6 and for the >> betas of 1.7 to define a release date in the vote thread, and then >> to build and publish the release "mechanically" on the release date. >> > > I may have been a bit unclear. This process simply doesn't comply > with ASF procedures. We cannot vote on the release of an artifact > that we haven't seen yet. We are required to check that the actual > released artifact is correct. Where correct is determined by a number > of criteria. > > http://incubator.apache.org/guides/releasemanagement.html > > There is something called RAT by Robert Burrel Donkins to check > compliance of artifacts, this is used by quite a few incubator folks. > I haven't used it myself yet. > > <http://code.google.com/p/arat/> > > Stefan > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
