On Tue, Mar 20, 2012 at 13:36, Daniel Pocock <dan...@pocock.com.au> wrote: > On 20/03/2012 17:34, Bernard Li wrote: >> On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocock<dan...@pocock.com.au> wrote: >> >>> I agree with that approach, with a slight variation - I'll tag it as >>> 3.3.3dp1 (after adding the ChangeLog file) >> >> Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 -> 3.3.3? > > > It is just a tag to help us keep track of what we test, it is not > intended for versioning a binary package > > However, if we want to be able to version binary packages using release > candidates, we may need to look at the problem more closely
It matters very much for RPM packages, and I suspect debian packages as well (although I don't know the details of building those). RPMs inherently understand version numbers, and that "3.3.2" is a more recent release than "3.3.1". There are some further syntactic bits added in, such as package release numbers (which are essentially, the least significant digit in the version), but the version number matters a great deal. I think that versions such as "3.3.3pre1", "3.3.3pre2" and "3.3.3" are handled correctly. These pages details the issue: http://fedoraproject.org/wiki/Tools/RPM/VersionComparison http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag There are some very ugly was to work around insane versioning schemes, but we don't have that problem (and shouldn't get into hacky workarounds) -- Jesse Becker ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
