>>> On 2/4/2010 at 6:50 AM, in message <4b6ad096.8030...@sara.nl>, Ramon >>> Bastiaans <ramon.bastia...@sara.nl> wrote: > Ahh, I see. > > On 02/04/2010 12:11 PM, Martin Knoblauch wrote: >> >> 3.1.3 .. 3.1.5 were canned during testing. Apparently our process does not > allow for fixing bugs/regressions between tagging and final release, so it > was decided to never publish the intermediates. >> >> > Perhaps in stead of tagging the "public beta" releases as a final > version, they could be tagged as "release candidate". I.e. call it > 3.1.6rc1 or 3.1.6pre1 or something similar. > >> One of the reasons might be lack of good beta testing (which I am guilty > of myself :-(, but I do not really understand, why we couldn't just keep > 3.1.3 > as the name of the release. >> >> > The public beta's are a good way to counter that, but it seems a bit > silly to me to skip entire version levels just because of release > procedures. >
The reason for skipping revision numbers is to make sure that we don't end up with confusion about a version in relation to what has already been released (I know, that statement in itself seems confusing but let me explain :). Each testing candidate is tagged with a release number and the tarball is built as if it were an official release. The tarball is then made available on the Ganglia site for testing. If the testing proves that the release candidate is valid, then the tarball is simply copied to the official release download site and becomes the official release. The status file and web page are also updated to reflect the release and corresponding release number. Under this process nothing had to be done to the actual physical tarball in order to transition it from a release candidate to an official release. BTW, the ganglia web site is correct, the current release is 3.1.2 and we are preparing 3.1.6 to go to testing. If we were to make release candidates publically available with a release number other than major.minor.revision (for example 3.1.3rc1), we would also be required to put this same release number in the source code itself to ensure that there is a differentiation between a release candidate and the official release since both would be made public (one during the testing period and the other being an official release). In order to transition the release candidate, in this case to an official release, we would be required to explode the tarball, change the version number, retag SVN with the changed file and revision number, re-boot strap the source code, recreate the tarball and then finally make the new tarball publically available under the final release number. All of this leaves the final tarball open to potential problems. It just makes more sense from a testing and release prospective to release the tarball in the exact condition as it was tested. This leaves no possibility for errors or problems creeping into the final released tarball. Another option would be to tag and tar the source code under the final release version number and make it available for testing. Then if bugs are found during testing, fix the bugs, retag and retar under the same version number. The problem with this is that we could end up with multiple different tarballs all with the same version number publically available. The only way to tell which one was the real release would be by the date on the tarball rather than version number. Anyway, you can read more about this process on the Ganglia wiki page at http://sourceforge.net/apps/trac/ganglia/wiki/how_project_works This release process was basically patterned after the way that the Apache httpd project produces testing and official tarballs. Brad ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
