Re: [Ganglia-developers] Ganglia 3.1.x release plan

[Brad N. <BNI...@no...>]

>>> On 7/10/2008 at 12:37 PM, in message
<d4c...@ma...>, "Bernard Li"
<be...@va...> 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 be 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