search

DrHyde / perl-modules-Number-Phone

Number::Phone and friends
24 stars 32 forks source link

Release 3.1 Breaks Dotted-Decimal Version Parsing #58

Closed theory closed 8 years ago

theory commented 8 years ago

The last release of Number::Phone was 3.1. Before that, it was 3.0014. Both were specified as strings. However, different systems interpret versions in different ways. Those that normalize versions using version.pm are fine, as it internally converts the values to dotted decimal. However, those that just do a naive dotted-decimal comparison, such as RPM, get confused. They think that 3.0014 resolves to 3.14, which is of course great than 3.1. Ow.

So I'm looking to hack my RPM building system to do something about this, but the simplest change for anyone else who might run into this is to never reduce the number of digits after a dot unless the digits before the dot increment. IOW, if the new version had been specified as

our $VERSION = '3.1000';

Then there would have been no confusion. If you were to release the next version with all the digits restored, I believe version comparison would go back to normal. If you want fewer than five digits after the dot at some point, the time to do it is when the whole number 3 increments to 4:

our $VERSION = '4.0';

Yes, this sucks. Versions suck.

theory commented 8 years ago

Here's my workaround.

DrHyde commented 8 years ago

I'll work-around this in the next release, but of course that only works for this software - and until I wonder why I've got all the extraneous zeroes in 3.200000000 and get rid of them. Could you point me at the bug reporting system for rpm, as this is obviously something that they need to fix.

DrHyde commented 8 years ago

Raised as http://rpm.org/ticket/904

theory commented 8 years ago

I'm not surprised they closed it. This is inherent in the challenge of numeric version numbers and dotted integer version numbers. version.pm does a lot of guesswork to try to compensate for this issue. RPM has no such smarts, not knowing the history of Perl module versioning. It's a mess, and is why I tend to only use x.xx versions for my Perl modules, so they're consistent (well, except for Sqitch), and semantic versions everywhere else.

theory commented 8 years ago

FWIW, I added a (fugly) workaround to rpmcpan to get around this issue. Yet another half-day lost to version numbering shenanigans.

This is why I require semver for PGXN releases. The alternative is simply madness.

DrHyde commented 8 years ago

I consider use of anything other than numbers (or text representations of numbers) as version numbers to be a bug. I thought that surely everyone would compare numbers to each other correctly. But no. Someone had to deliberately write code to make them compare incorrectly. Someone actually went out of their way, did work, to break number comparison.

My rules of version numbers: 1) they should be numbers 2) they should go up.

Semver is a nice idea, and I've used it in the past, but I gave up when I realised how utterly fucked up and broken software support for it was. And unless everyone has exactly the same understanding of what bumping each part of version X.Y.Z means (and they don't) then it doesn't help with communicating anything.

theory commented 8 years ago

Yep, versions suck, and opinions and interpretations are all over the place.