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. http://en.wikipedia.org/wiki/Busy_work ;-)

Craig
>
>
>> 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
> cziegeler@apache.org

Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message