Bug #93340 for version: version->parse(q[2.6_01])->normal gives v2

Tue Feb 25 07:19:25 2014 dolmen [...] cpan.org - Ticket created

Subject:

version->parse(q[2.6_01])->normal gives v2_601.0

As reported by kentnl on IRC: $ perl -Mversion -E 'say version->parse(q[2.6_01])->normal' v2_601.0 -- Olivier Mengué - http://perlresume.org/DOLMEN

Tue Feb 25 08:25:32 2014 KENTNL [...] cpan.org - Requestor KENTNL added

Tue Feb 25 08:25:32 2014 KENTNL [...] cpan.org - Correspondence added

And as a result, it doesn't round-trip either:

perl -Mversion -E'say version->parse(version->parse(q[2.6_01])->normal)->normal'
Invalid version format (non-numeric data) at -e line 1.

Tue Feb 25 12:07:20 2014 ether [...] cpan.org - Cc ETHER added

Tue Feb 25 20:54:57 2014 jpeacock [...] cpan.org - Correspondence added

On Tue Feb 25 08:25:32 2014, KENTNL wrote: Show quoted text

> And as a result, it doesn't round-trip either: > > perl -Mversion -E'say > version->parse(version->parse(q[2.6_01])->normal)->normal' > Invalid version format (non-numeric data) at -e line 1.

If it's any consolation, the pure Perl code has precisely the same behavior. :-(

Tue Feb 25 20:54:57 2014 The RT System itself - Status changed from 'new' to 'open'

Tue Feb 25 22:17:26 2014 jpeacock [...] cpan.org - Correspondence added

On Tue Feb 25 20:54:57 2014, JPEACOCK wrote: Show quoted text

> On Tue Feb 25 08:25:32 2014, KENTNL wrote:

> > And as a result, it doesn't round-trip either: > > > > perl -Mversion -E'say > > version->parse(version->parse(q[2.6_01])->normal)->normal > > Invalid version format (non-numeric data) at -e line 1.

Looking at this in detail, there is no possible way to convert that alpha string into an equivalent dotted-decimal form, let alone one that will round-trip. I've been regretting exposing normal() and numify() for years; I'm thinking of releasing 1.0.0 and removing those functions from the public API entirely. I'm rejecting this bug. I will not make this work. I /will/ make it an error to call normal() on a non-qv alpha version. That is the only sensible thing to do.

Tue Feb 25 22:17:27 2014 jpeacock [...] cpan.org - Status changed from 'open' to 'rejected'

Wed Feb 26 01:20:53 2014 KENTNL [...] cpan.org - Correspondence added

On 2014-02-26 16:17:26, JPEACOCK wrote:
> On Tue Feb 25 20:54:57 2014, JPEACOCK wrote:
> > On Tue Feb 25 08:25:32 2014, KENTNL wrote:
> > > And as a result, it doesn't round-trip either:
> > >
> > > perl -Mversion -E'say
> > > version->parse(version->parse(q[2.6_01])->normal)->normal
> > > Invalid version format (non-numeric data) at -e line 1.
>
> Looking at this in detail, there is no possible way to convert that
> alpha string into an equivalent dotted-decimal form, let alone one
> that will round-trip. I've been regretting exposing normal() and
> numify() for years; I'm thinking of releasing 1.0.0 and removing those
> functions from the public API entirely.
>
> I'm rejecting this bug. I will not make this work. I /will/ make it
> an error to call normal() on a non-qv alpha version. That is the only
> sensible thing to do.

As a compromise, would you contemplate, an alternative where alpha bits are simply lost in normalizations?

Internal Perl doesn't care about Alpha anyway, and Alpha is only supposed to be human interface, not perl-interface detail.

Even if you have to pass a parameter to either support, or reject these, thats better than "oh, just die".

So in summary:

version->parse(q[2.6_01])->normal # should yield v2.601.0
version->parse(q[2.6_01])->normal( strict => 1 ) # could error

It just seems far less desirable to explode when normalising a perfectly valid perl version.

After all:

version->parse(q[2.6_01])->numify

Does not attempt to preserve the _

And

perl -Mversion -E 'say version->parse(version->parse(q[2.6_01])->numify)->normal'
v2.601.0

seems quite valid.

Wed Feb 26 03:54:55 2014 ribasushi [...] leporine.io - Cc RIBASUSHI added

Thu Feb 27 04:59:57 2014 LEONT [...] cpan.org - Correspondence added

On Wed Feb 26 01:20:53 2014, KENTNL wrote: Show quoted text

> On 2014-02-26 16:17:26, JPEACOCK wrote:

> > On Tue Feb 25 20:54:57 2014, JPEACOCK wrote:

> > > On Tue Feb 25 08:25:32 2014, KENTNL wrote:

> > > > And as a result, it doesn't round-trip either: > > > > > > > > perl -Mversion -E'say > > > > version->parse(version->parse(q[2.6_01])->normal)->normal > > > > Invalid version format (non-numeric data) at -e line 1.

> > > > Looking at this in detail, there is no possible way to convert that > > alpha string into an equivalent dotted-decimal form, let alone one > > that will round-trip. I've been regretting exposing normal() and > > numify() for years; I'm thinking of releasing 1.0.0 and removing > > those > > functions from the public API entirely. > > > > I'm rejecting this bug. I will not make this work. I /will/ make it > > an error to call normal() on a non-qv alpha version. That is the only > > sensible thing to do.

> > As a compromise, would you contemplate, an alternative where alpha > bits are > simply lost in normalizations? > > Internal Perl doesn't care about Alpha anyway, and Alpha is only > supposed to be > human interface, not perl-interface detail.

IMO, caring about that underscore was the mistake in the first place. Show quoted text

> Even if you have to pass a parameter to either support, or reject > these, thats > better than "oh, just die". > > So in summary: > > version->parse(q[2.6_01])->normal # should yield v2.601.0 > version->parse(q[2.6_01])->normal( strict => 1 ) # could error > > It just seems far less desirable to explode when normalising a > perfectly valid > perl version.

That may not be a bad option. Leon

Thu Feb 27 05:47:14 2014 LEONT [...] cpan.org - Cc LEONT added

Sat Mar 01 12:16:48 2014 john.peacock [...] havurah-software.org - Correspondence added

Subject:	Re: [rt.cpan.org #93340] version->parse(q[2.6_01])->normal gives v2_601.0
Date:	Sat, 01 Mar 2014 12:16:37 -0500
To:	bug-version [...] rt.cpan.org, undisclosed-recipients:;
From:	John Peacock <john.peacock [...] havurah-software.org>

On 02/27/2014 04:59 AM, Leon Timmermans via RT wrote: Show quoted text

> IMO, caring about that underscore was the mistake in the first place.

That ship sailed long ago and there is no point in arguing about it now. Show quoted text

>> version->parse(q[2.6_01])->normal # should yield v2.601.0 >> version->parse(q[2.6_01])->normal( strict => 1 ) # could error >> >> It just seems far less desirable to explode when normalising a >> perfectly valid >> perl version.

> > That may not be a bad option.

How about this for a compromise: both normal() and numify() will now throw a warning about the operation being lossy for alpha versions, so it will be painfully clear that you cannot round-trip those conversions. If you don't like the possibility that your code might emit warnings, just add no warnings qw/version/; at the appropriate place in your code. My core issue is that I think both numify() and normal() are being abused to do something that version objects were never intended to support. Yes, you can /compare/ a decimal with a dotted-decimal version, but you should never assume you can freely transform one form into the other. They have always intended to be read-only opaque objects. John

Sat Mar 01 18:24:21 2014 LEONT [...] cpan.org - Correspondence added

On Sat Mar 01 12:16:48 2014, john.peacock@havurah-software.org wrote: Show quoted text

> On 02/27/2014 04:59 AM, Leon Timmermans via RT wrote:

> > IMO, caring about that underscore was the mistake in the first place.

> > That ship sailed long ago and there is no point in arguing about it now.

I'm not sure it's too late for that. I honestly believe the number of things that would unbreak would be bigger than the number of things we'd break. Show quoted text

> How about this for a compromise: both normal() and numify() will now > throw a warning about the operation being lossy for alpha versions, so > it will be painfully clear that you cannot round-trip those conversions. > If you don't like the possibility that your code might emit warnings, > just add > > no warnings qw/version/; > > at the appropriate place in your code.

That may be reasonable, I'd have to think about it a bit more. Show quoted text

> My core issue is that I think both numify() and normal() are being > abused to do something that version objects were never intended to > support. Yes, you can /compare/ a decimal with a dotted-decimal > version, but you should never assume you can freely transform one form > into the other. They have always intended to be read-only opaque objects.

Perl's versions need to interact with the outside world. Opaque objects are of no use to for example packagers, or to humans for that matter. Truly opaque versions are essentially unusable. Leon

Sun Mar 02 10:43:19 2014 john.peacock [...] havurah-software.org - Correspondence added

Subject:	Re: [rt.cpan.org #93340] version->parse(q[2.6_01])->normal gives v2_601.0
Date:	Sun, 02 Mar 2014 10:43:06 -0500
To:	bug-version [...] rt.cpan.org, undisclosed-recipients:;
From:	John Peacock <john.peacock [...] havurah-software.org>

On 03/01/2014 06:24 PM, Leon Timmermans via RT wrote: Show quoted text

> I'm not sure it's too late for that. I honestly believe the number of things that would unbreak would be bigger than the number of things we'd break.

And by too late, I mean specifically that I am completely out of plutonium to power my time machine to fix the core Perl version code in v5.10.x. I cannot in good conscience make a CPAN install mandatory for older Perl releases because we want to alter this one behavior. Show quoted text

> Perl's versions need to interact with the outside world. Opaque objects are of no use to for example packagers, or to humans for that matter. Truly opaque versions are essentially unusable.

Opaque in the sense that the only reliable means of dealing with the objects is using their own interface, not trying to force them into some preconceived format. Printing a version object ( implnicitly stringifying it) produces a consistent value, no matter what the underlying storage contains. That is the only interface that matters. If your packaging system only understands decimal versions (and you can't admit to yourself that your packaging system is horrifically broken), then you have no choice but to numify any dotted-decimal version _for your own use_. But you are fooling yourself if you think that is anything but a hack; only the module author can decide what $VERSION they want to assign to their package. All that version objects can do is provide an equivalence between the two forms. The numified form is NOT the same thing as the normal form; that are there for comparison purposes only. I would love to have had SemVer defined before I started working on version objects. I would have eliminated the entire class of alpha versions to start with. John

Sat Jan 17 22:36:55 2015 jpeacock [...] cpan.org - Correspondence added

The fix for this broke Module::Build, so withdrawing it...

Sat Jan 17 22:36:57 2015 jpeacock [...] cpan.org - Status changed from 'rejected' to 'open'

Sat Jan 17 22:36:57 2015 jpeacock [...] cpan.org - Fixed in 0.9910 added

Sun Jan 18 06:09:41 2015 jpeacock [...] cpan.org - Correspondence added

On Sat Jan 17 22:36:55 2015, JPEACOCK wrote: Show quoted text

> The fix for this broke Module::Build, so withdrawing it...

Patch provided upstream to M::B and pull requested. If that is accepted, I will reapply the changes to fix this bug and release 0.9912.

Sun Jan 18 06:09:42 2015 jpeacock [...] cpan.org - Fixed in 0.9911 added

Sun Jan 18 06:09:43 2015 jpeacock [...] cpan.org - Fixed in 0.9910 deleted

Fri Jan 01 09:41:13 2016 jpeacock [...] cpan.org - Correspondence added

Resolved for real by Lyon Compromise code in 0.9913

Fri Jan 01 09:41:15 2016 jpeacock [...] cpan.org - Status changed from 'open' to 'resolved'

Bug #93340 for version: version->parse(q[2.6_01])->normal gives v2_601.0