----- Original Message ---- > From: Brad Nicholes <bnicho...@novell.com> > To: Martin Knoblauch <kn...@knobisoft.de>; Ramon Bastiaans > <ramon.bastia...@sara.nl> > Cc: "ganglia-developers@lists.sourceforge.net" > <ganglia-developers@lists.sourceforge.net> > Sent: Thu, February 4, 2010 4:33:31 PM > Subject: Re: [Ganglia-developers] versioning confusion > > >>> On 2/4/2010 at 6:50 AM, in message <4b6ad096.8030...@sara.nl>, Ramon > Bastiaans > wrote: > > Ahh, I see. > > > > On 02/04/2010 12:11 PM, Martin Knoblauch wrote: > >> > > 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.
So, why not put the "rc" or "pre" Tag into an GANGLIA_EXTRA_VERSION and embed that into the code. That way there would be no confusion about what is in the tarball. Then we could have as many testing releases before the final one. SVN tags are cheap. What am I missing? I mean, now we are confuing people with skipped "releases". > > 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. > much to convoluted and confusing. Agreed. > 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. > As I said in the past, that process may work for Apache. I do not see many skipped releases there. Maybe they have a more strict project management. Personally I think Ganglia is to small for that. Watching the discussions here, I see us spend more time on "process" than on "progress". But I maybe burnt by day-job. There I am forced to follow a lot of completetly bogus (technically) processes, just to make some beancounters an process-engineers happy (no, I dont like either). Cheers Martin ------------------------------------------------------------------------------ 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
