On Mon, Aug 25, 2008 at 10:11:42AM -0600, Brad Nicholes wrote: > >>> On 8/22/2008 at 10:59 AM, in message <[EMAIL PROTECTED]>, Carlo > Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > > > > it was discussed in the list as one of the reasons why we couldn't get > > a stable release package done, and since it is dead code and it is of no > > use anywhere removing it was the obvious solution to that. > > IIRC, the discussion was around whether or not a release name was required > in order to produce a release. IMO, the release name is optional given > that the version number is really the unique identifier of a release.
As I mentioned before the release is identified by both a version number and release name as shown by the configure output and our release announcements and since the release name is in the code it can't be changed once a stable tag has been created and so as you explained below is needed before a stable release can be generated. > But that doesn't mean that the release name is dead code. If it is not being used anywhere in the produced package is by definition "dead code"; getting it propagated to the version file for the frontend and not used anywhere there is an example of it being dead code as well, even if you could argue that printing it in configure's output during the build process is a use of it and if that is the case I agree and had updated the backport proposal accordingly. > Apparently people still like associating a release name with a package, > which is OK. That just means that part of the procedure before actually > tagging a testing release is to assign a release name which could happen > right up to the last minute before tagging. Agree, except that waiting up to the last minute before tagging blocks anyone who would want (or was instructed as in this case) to generate an official release (either for testing or production) to do so and therefore could be a reason for delaying a release or to have to resort to having unofficial packages which are just confusing. Indeed, as explained in this thread (*) the whole objective for this proposal was to avoid any artificial delays to be introduced (specially considering that for 3.1.1 it took 18 days from proposal to commit) and to save the extra effort required to maintain release names, specially considering the size of our development team, but I have no problem at all with keeping them if that risk is averted by doing whatever is needed to come out with a release name soon enough so it can be used as soon as development for a new release is started (which requires updating the version number anyway) > I think Bernard probably has that covered. As usual and as expected as the "de facto" release manager, and which IMHO is a perfectly good way to come out with release names in short time periods as mentioned also in this thread. Carlo (*) http://www.mail-archive.com/ganglia-developers@lists.sourceforge.net/msg04702.html ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
