Skip Menu |

This queue is for tickets about the version CPAN distribution.

Report information
The Basics
Id: 48291
Status: rejected
Priority: 0/
Queue: version
People
Owner: Nobody in particular
Requestors: cmr [...] financial.com
Cc:
AdminCc:
Bug Information
Severity: Wishlist
Broken in: 0.7701
Fixed in: 0.7701

History Show all quoted text
  Wed Jul 29 08:51:58 2009 cmr [...] financial.com - Ticket created
Subject: Version numbering
Please consider not changing the length of the version number parts to make packageing easier.
  Wed Jul 29 10:01:48 2009 john.peacock [...] havurah-software.org - Correspondence added
Subject: Re: [rt.cpan.org #48291] Version numbering
Date: Wed, 29 Jul 2009 10:01:28 -0400
To: bug-version [...] rt.cpan.org
From: John Peacock <john.peacock [...] havurah-software.org>
Christoph Maser via RT wrote: Show quoted text
> Please consider not changing the length of the version number parts to > make packageing easier.
Could you be more specific? In general, it is never reliable to assume any specific length for an externally maintained value (like $VERSION in someone else's package). As long as the $VERSION numbers are sortable (ASCII-wise is most common for filenames), then there should really be no issue. RPM is particularly "good" at this; the 'Version' field is compared very much like version.pm objects are: compare as array of decimals separated by periods, then the 'Release' field is compared ASCII-wise (free form). John
  Wed Jul 29 10:01:50 2009 The RT System itself - Status changed from 'new' to 'open'
  Wed Jul 29 10:40:16 2009 cmr [...] financial.com - Correspondence added
Show quoted text
> RPM is particularly "good" at this; the 'Version' field is compared very > much like version.pm objects are: compare as array of decimals separated > by periods, then the 'Release' field is compared ASCII-wise (free form).
Actually RPM is what I care about (packaging for rpmforge) what we oftan have is releases like 0.1 -> 0.1011 -> 0.2 In RPM the sort order would be 0.1 -> 0.2 -> 0.1011 since 1011 > 2, so hat we (and others) often do is to either fill up the varying length with zeros or split the version number ourselves, like i did split up 0.7701 to 0.77.1
  Wed Jul 29 10:46:23 2009 john.peacock [...] havurah-software.org - Correspondence added
Subject: Re: [rt.cpan.org #48291] Version numbering
Date: Wed, 29 Jul 2009 10:46:02 -0400
To: bug-version [...] rt.cpan.org
From: John Peacock <john.peacock [...] havurah-software.org>
Christoph Maser via RT wrote: Show quoted text
> Actually RPM is what I care about (packaging for rpmforge) what we oftan > have is releases like 0.1 -> 0.1011 -> 0.2 > In RPM the sort order would be 0.1 -> 0.2 -> 0.1011 since 1011 > 2, so > hat we (and others) often do is to either fill up the varying length > with zeros or split the version number ourselves, like i did split up > 0.7701 to 0.77.1
Except that should be 0.770.100 (strictly speaking). I am hesitant to use dotted-decimal versioning for the version.pm releases (since that is essentially a bootstrapping issue). However, there is a proposed patch for ExtUtils::MakeMaker to include an internal version.pm (much like Module::Build already does). This would mean authors could just assume that version objects will Just Work everywhere... John
  Sun Sep 13 07:00:58 2009 jpeacock [...] cpan.org - Status changed from 'open' to 'rejected'