incubator-sanselan-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Sanselan 0.93 Release Vote
Date Wed, 23 Jul 2008 05:49:49 GMT
Craig L Russell wrote:
> The process doesn't have to fail if you want to respin a build.
> You can have as many votes as you like for the same release 0.93.
Yes, that's possible - but I think it's good practice to cut a new 
release with a new version number each time to reduce possible 
confusion. Like Roy once said "version numbers are cheap" :)
I know that in this case it's very unlikely to happen, but imagine that 
someone already checked out the 0.93 tag from yesterday and distributed 
it. If we recut a release with the same version numbers there will be 
two different 0.93 releases out there. Which one is the official?
So we avoid this by just incrementing the version number.

> You are right that the general at incubator list doesn't really want to 
> watch the dev list iterate until there is a release that the dev team is 
> happy with. Then, when dev is happy, you post the vote on general at 
> incubator.
Yes, so first vote on this list until "we" are happy :) then second vote 
on general.

> The normal practice is for votes to have a subject line that includes 
> [VOTE] in the subject line.
> If a vote fails, you can call another vote with a note like (second try) 
> in the subject line, if you are keeping the same artifact name.
> Alternatively, you can add more descriptive tags to the path of the 
> artifacts, e.g. 
> ~cmchen/dist/incubator/sanselan/0.93-try2/sanselan-0.93-incubating-bin.tar.gz. 
> After a successful vote of 0.93-try2 you can rename the path before 
> copying it (or copy it with the correct name).
> Of course, it's also ok to respin with a complete new release number, 
> but as you've seen, changing the path names and pom version numbers is 
> pretty painful if all you need to do is to change a few bits and respin 
> the release.
> Whatever process the team decides on, it should be documented in the svn 
> tree, perhaps in a high level document (at the same level as trunk) 
> called HowToRelease.txt or something similar. The process for release 
> naming and tagging/branching should also be documented.


Carsten Ziegeler

View raw message