>>> On 7/10/2008 at 12:37 PM, in message
<[EMAIL PROTECTED]>, "Bernard Li"
<[EMAIL PROTECTED]> wrote:
> Dear all:
> 
> Here's the release plan for the upcoming 3.1 release.
> 
> I believe all the important, show-stopping backport proposals in the
> STATUS file for 3.1 branch have already been processed and voted on.
> So all the remaining backport proposals will be moved from "BACKPORT
> PROPOSALS" to "BACKPORT PROPOSALS NEXT VERSION" except for
> documentation patches.
> 
> As for...
> 
> * gmond: avoid latency and timeouts when using the tcpconn python module
> 
> If this causes issues, we could just turn it off by default and put in
> documentation about its potential pitfalls on certain platforms.
> 
> Let's get this done by Friday and roll out a beta.  We'll test this
> for a week, and roll out RC1, RC2, etc. etc.
> 

I would just like to make a comment about version numbers as we are about to 
generate our first release of 3.1.  I noted this on the wiki several months ago 
under the section "Generating a Release Candidate and GA Release" 
(http://ganglia.wiki.sourceforge.net/ganglia_works) which describes the same 
release versioning process that the Apache project uses.  This also goes back 
to our discussions about 3.1.0 vs. 3.1.1 version number.  

The Apache project does not use the labels Alpha, Beta, RCx for any of the 
actual tarball file names or internal version numbers in the source code 
itself.  The only time these labels are used are in the mailing list 
announcements during the testing period.  The reason why these labels are not 
used in the file name or in the source code is so that a tarball only has to be 
rolled once and if determined during the testing period to be releasable, no 
alterations to the actual tarball are made.  It is simply released officially.  
What this means is that if a 3.1.1 tarball is tagged in SVN, rolled, posted for 
testing and fails testing, that version number is simply thrown away.  Once the 
fix is made in trunk and backported, a new tag is created (ie. 3.1.2) in SVN, 
the tarball is rolled and the process starts over again.  If the "Beta" or 
"RCx" label were used in the source code or file name, source code changes 
would have to be made (even though minor), the tarball would have to b
 e re-rolled which carries a potential of reintroducing a bug or build issue.  
Another advantage to this is that all public releases (including betas or RCs) 
of a tarball are tracked in SVN.  It also avoids any potential confusion 
because multiple testing tarballs carried the same version number as the actual 
release.  The only downside to this is the fact that our first official release 
might be 3.1.3 or rather than 3.1.0.  This could be a little mis-leading to 
some users however the Apache project has been successfully doing this for a 
long time with no problem or confusion.  The first release of Apache 2.0 was 
not 2.0.0 it was actually 2.0.35.  

NOTE: I do have to mention that the first release of Apache 2.2 was actually 
2.2.0, but that was because the Apache project moved to an odd/even versioning 
scheme (like the linux kernel) where all odd minor version numbers are 
considered "in-development" and all even minor version numbers are releases.  
That is why nobody ever saw an official Apache 2.1 release but rather skipped 
directly to 2.2.  All 2.1.x versions were development/testing only. We could do 
that as well, but that hasn't been the precedence so far in the Ganglia 
project.  If we did, then our first official release would be 3.2.0 rather than 
3.1.<whatever>.  My preference would be to stick to the 3.1.x scheme as 
described in the wiki and the paragraph above.

Comments?

Brad


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers

Reply via email to