>>> On 2/5/2010 at 3:58 AM, in message <815639.84803...@web113311.mail.gq1.yahoo.com>, Martin Knoblauch <kn...@knobisoft.de> wrote: > ----- 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". >
Basically for the reasons that I mentioned above. Agreed that SVN tags are cheap but the major reasons are to reduce the number of publically available tarballs and to make sure that the release process itself does not allow for problems to creep into the code. By releasing exactly what we are testing, it reduces the number of steps in the testing and release process and at the same time ensures that an officially released tarball is exactly the same tarball that was tested and approved by the community during the testing period. Also remember that we haven't ever skipped a "release". We have only skipped revision numbers. The Ganglia web site and the sourceforge project site are still the definitive authority on what our current release is. By simply checking those sites, there should be no question or confusion on what our current release is. It would be a big mistake for someone to pull a tarball from the testing download area and deploy that into their production environment. Like every other project, the only official download area, as far as the Ganglia project is concerned, is the sourceforge down web page and currently the latest release available on that site is 3.1.2. If, hopefully in a few weeks, we release 3.1.6 or whatever the final revision number is, that will become the official Ganglia release and it really doesn't matter what happened to any of the previous revisions. > > >> 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. > It isn't really that the project management is more strict for Apache, it is more a matter of the number of contributors, testers and eyes that they have on the project. Given the fact that the Ganglia project has relatively few developers or testers and that testing feedback is very small to almost none, the likelihood of bugs falling through the cracks which would cause a testing revision to be scraped, is much higher for the Ganglia project than it is for Apache. Size of the community is really the major factor. But the process is still good and does what it is suppose to do. > 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). > I hear you on that. Over the past couple of years there has been a lot of talk about process, but at the same time there has also been a lot of progress made in the source code. The difference in functionality between the 3.0.x and 3.1.x branches is very significant. The whole idea here is to not only improve the code but to also grow the community which I think we have also done to a certain extent. In order to try to minimize the confusion over how the project works (or what has changed in the process), I have tried to make sure that everything has been documented on the wiki site. I think that one of the mistakes that I made initially was that I introduced too much process in to the code development and releases. That is the main reason why about a year ago, I backed off significantly and suggested a new set of guidelines for development rather than process rules. All of that has been documented as well and hopefully working better. 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
