incubator-sanselan-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Sanselan 0.93 Release Vote
Date Wed, 23 Jul 2008 15:14:54 GMT
Hi Carsten,

I guess one key reason for having multiple mentors is that no two  
Apache people agree on anything. ;-)

On Jul 22, 2008, at 10:49 PM, Carsten Ziegeler wrote:

> 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" :)

Not necessarily. Right now, there's little difference between 0.93 and  
0.94. But if you're planning a 1.0 release and have a failed vote, I'd  
sure hate to ditch it and make a maintenance release or two before  
you're out the gate.
> 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.

That's why I recommend *not* tagging a release until it's been voted  
out the door. While the release manager is working on a branch, it's  
not official.

And besides, what process is it by which some random person checked  
out a tag and distributed it? It's just as likely that some random  
person checked out the trunk and distributed it as 1.0.

> Which one is the official?
> So we avoid this by just incrementing the version number.

My input is to suggest that the team create a process that doesn't  
involve busy work and is transparent to the developers and users.  
Respinning a release is work; changing the release number is busy  
work. ;-)

>> 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.
> +1
> Carsten
> -- 
> Carsten Ziegeler

Craig L Russell
Architect, Sun Java Enterprise System
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message