Bug #54897 for Parse-RecDescent: Version numbers must never decrease length for ease of packaging

Show quoted text
Okay. Will do. But I'm clearly missing something obvious here because I don't see how 1.964 (or any future version numbers in that D.DDD, format) will ever compare incorrectly against any previous version number the module has had, either numerically or stringifically. I'm evidently not smart enough to grasp the actual issue, so I'd really be grateful if you could spare a minute to give me an example of the problem those extra three digits are solving. Thanks, Damian

On Mon, Feb 22, 2010 at 11:45:53PM -0500, damian@conway.org via RT wrote: Show quoted text
Ok. 1.962.2 expands as 1.962002 so that's how people dep on it, since that's how the numeric equality works. But this means that the system gets a requirement for that, and 1.962002 > 1.964 but 9620002 < 1.964 So if you're going to do three part version numbers, you need to always use them once you've adopted them - or convert to a six digit minor version and stay there. Reducing the number of digits in a two part version has the same problem - 1.81 > 1.8001 but 81 < 8001 and you run into the same problem. Basically, version numbers suck, BUT if you never DECREASE the size of your minor version (within a given major version) then your version numbers are consistent under both interpretations and work for everybody. Show quoted text
-- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.uk http://shadowcat.co.uk/blog/matt-s-trout/

On Tue, Feb 23, 2010 at 05:55:51PM -0500, damian@conway.org via RT wrote: Show quoted text
Actually, it's worse than that. Show quoted text
2. Everything that isn't sure its users can handle multipart represents this as 1.962001 In this case, SQL::Translator did so which caused that version number to be introduced into the arch linux packaging system. Show quoted text
And this is all that was required. Because that has decimal version 1.964. So if somebody *then* treats decimal 1.962001 as multipart 1.962001.0 it doesn't compare right to multipart 1.964.0. Show quoted text
And some packaging systems treat CPAN versions as decimal and some as multipart (same goes for cpan authors, SQL::Abstract went 0.1 ... 0.9, 0.10, 0.11, ...). Show quoted text
Actually, no, it's worse than that. You have to assume that dependency systems never reliably distinguish between them and that any given system you encounter may simply assume one or the author. Show quoted text
You always have to ensure that. But once you've used multipart at all, you have to ensure that the decimalisation of your versioning from then on works under both interpretations. You can reliably expect a decimal system to treat 1.962.1 as sprintf("%i.%03i%03i", split(/\./, $version)) - or at least I've not *yet* seen that violated. But really what that means is "you now have a 6-digit fractional part for the decimal version of your multipart". That's one rule. The second is "your decimal version must also work as a two-part multipart". Rule 2 is what makes 0.81 after 0.8001 bad in general. Rule 1 is how you managed not to realise you'd effectively had a 6 digit decimal and then gone to a 3 digit one. Does that clear things up, in so far as this subject can ever be clear? Show quoted text
I'm not finding it a waste, I'm finding it an effective means of eliciting a clear explanation of this that can be re-used to educate other CPAN authors. -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.uk http://shadowcat.co.uk/blog/matt-s-trout/

On Wed, Feb 24, 2010 at 12:36:17AM -0500, damian@conway.org via RT wrote: Show quoted text
Decimal with the proviso of "never reduce the number of digits after the ." works fine. Multipart as a human version with X.YYYzzz as the machine/decimal version works fine. I personally dislike date-based because a good human readable version indicates things to the user - notably "api version, feature additions within this api version, bugfix release" for the X, Y and Z respectively. And I can read 0.08112 > 0.08109 much much easier than 20081102 > 20081030 when skimming information. Once you get the rule of thumb down it's actually very easy to do right and still be able to do reasonable things with your versions; the hard part is understanding the baroque madness that requires the "never reduce" rule. It'd be a shame to switch versioning styles now after you've already lost the SAN points ... :) -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.uk http://shadowcat.co.uk/blog/matt-s-trout/

Thank you for the bug report, and detailed explanations. Following Damian's lead, I'll be keeping version numbers in the following forms: X.YYYzzz X.YYY_zzz Along with this code from perlmodsub: our $VERSION = "X.YYY_zzz"; $version = eval $VERSION; to allow for decimal comparisons by modules that use Parse::RecDescent. Also, X, YYY and zzz will only ever increment. I believe that this will address the issues you've raise. If this isn't sufficient, please reopen the bug. Thanks! Jeremy