I don't really want to make a big deal out of this but I thought it was long agreed that we would tag a release (eg. 3.3.2) and that would potentially be our "Release Candidate". If everything is fine, we will just release as is otherwise we will discard 3.3.2, bump the version to 3.3.3 and repeat the cycle.
This way, there is a natural way to do upgrades via RPM but the downside is that we might artificially bump up our version numbers by quite a bit for official releases. Anyways, this is just my $0.02. Cheers, Bernard On Tue, Mar 20, 2012 at 11:00 AM, Daniel Pocock <dan...@pocock.com.au> wrote: > On 20/03/2012 17:57, Jesse Becker wrote: >> >> 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 > > > According to that document, any suffix will make a version appear to be > newer than the version without a suffix > > E.g., if RPM sees both 3.3.3pre1 and 3.3.3, it will believe 3.3.3pre1 is > newer > > Therefore, we would need to have some suffix that we use for the final > release too > > Before deciding on that though, it would be really useful to understand: > > a) just how much testing do people want to make with release candidates? > Are people building RPMs and putting them in yum catalogues, etc, and > expecting that to work? > > b) or is it just sufficient to build a package that can be manually > installed (without yum) on a single box as a sanity check? > > c) and how do we find a common solution for all other platforms (Debian, > OpenCSW, etc)? ------------------------------------------------------------------------------ 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
