ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy-Lambert <anto...@gmx.de>
Subject Re: A note on release votes
Date Sat, 28 Oct 2006 14:56:17 GMT
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 <antoine@gmx.de> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message