On Wed, 2007-10-10 at 15:50 -0700, Bernard Li wrote: > The issue is, if I am to release test RPMs, and later wanted to > upgrade to the release version, this won't work because 3.1.0.XXXXX > > 3.1.0. > > I would like to propose that prior to release, the version is always > smaller than the released version, so perhaps we should make the > version in trunk 3.0.9, and when release comes around, we change it to > 3.1.0, tag, then release.
My personal preference is to have the "version" part of the rpm name accurately reflect the package I am installing. If I see a package named ganglia-3.0.9-<release>, my expectation is that I am installing some form of ganglia-3.0.9. In this case, ganglia-3.0.9 doesn't really exist (in the sense that there is no official tagged ganglia-3.0.9 version). I found this page from the Fedora project about RPM naming that might be useful: http://fedoraproject.org/wiki/Packaging/NamingGuidelines I'm not saying that Ganglia needs to follow this convention, but it does have some good ideas about how to handle rpm names for betas, pre- releases, snapshots, etc. Basically, it relies on the "release" field to convey this information while still maintaining a strictly increasing <version>-<release> number. Maybe one of those ideas could be used/adapted to address the problem mentioned above. -- Rick Mohr Systems Developer Ohio Supercomputer Center ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
