Bug #65753 for version: Allow "alpha without decimal" versions

Tue Feb 15 19:53:04 2011 mschwern [...] cpan.org - Ticket created

Subject:

Allow "alpha without decimal" versions

version.pm will not accept "alpha without decimal" versions. $ perl -wle 'use version; print version->new("20110216_01")' Invalid version format (alpha without decimal) at -e line 1. This makes ISO date integer versions difficult to work with, I have to put in a bogus decimal part. There's a specific comment about this case in the the code, "underscore can't come after integer part". Seems arbitrary, could that restriction be removed?

Wed Feb 16 11:15:54 2011 john.peacock [...] havurah-software.org - Correspondence added

Subject:	Re: [rt.cpan.org #65753] Allow "alpha without decimal" versions
Date:	Wed, 16 Feb 2011 11:15:34 -0500
To:	bug-version [...] rt.cpan.org
From:	John Peacock <john.peacock [...] havurah-software.org>

On 02/15/2011 07:53 PM, Michael G Schwern via RT wrote: Show quoted text

> This makes ISO date integer versions difficult to work with, I have to > put in a bogus decimal part. There's a specific comment about this case > in the the code, "underscore can't come after integer part". Seems > arbitrary, could that restriction be removed?

My gut reaction is to say "No, I'm not changing version.pm except for bug fixes", but I can see your point. Would it be acceptable to have a subclass called version::ISO-8601 which could actually do the correct thing and validate the version string as a well-formed ISO-8601 date. I started to think about this when I read your e-mail this morning and even started on a shallow implementation. It really isn't a big deal to subclass version.pm (I wrote it with that in mind). You just need new(), cmp/spaceship, and whatever stringification you want. What do you think? John

Wed Feb 16 11:15:55 2011 The RT System itself - Status changed from 'new' to 'open'

Wed Feb 16 19:51:10 2011 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #65753] Allow "alpha without decimal" versions
Date:	Thu, 17 Feb 2011 11:50:53 +1100
To:	bug-version [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

On 2011.2.17 3:15 AM, John Peacock via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=65753 > > > On 02/15/2011 07:53 PM, Michael G Schwern via RT wrote:

>> This makes ISO date integer versions difficult to work with, I have to >> put in a bogus decimal part. There's a specific comment about this case >> in the the code, "underscore can't come after integer part". Seems >> arbitrary, could that restriction be removed?

> > My gut reaction is to say "No, I'm not changing version.pm except for > bug fixes", but I can see your point. Would it be acceptable to have a > subclass called version::ISO-8601 which could actually do the correct > thing and validate the version string as a well-formed ISO-8601 date.

Sorry, that it's an ISO date is just a convention to add some meaning to an otherwise meaningless number. There's little point in parsing it. Maybe I miscommunicated. That it's an ISO date is a red herring. The request is that integer versions be allowed to have an alpha part. version->parse("123_45"); I don't expect you to do the patching (it wouldn't hurt) but I do need to know your thoughts on whether 123_45 should be valid. Then I can work up a patch. Apparently this came in 0.52 and rt.perl.org 37897 http://rt.perl.org/rt3//Public/Bug/Display.html?id=37897 https://github.com/gitpan/version/commit/56a64721d2debd0c23312358c612b9c0215eca59 Reading that discussion, I'm not sure how it equates to banning 123_45. Is it possibly an overzealous restriction? Show quoted text

> I started to think about this when I read your e-mail this morning and > even started on a shallow implementation. It really isn't a big deal to > subclass version.pm (I wrote it with that in mind). You just need > new(), cmp/spaceship, and whatever stringification you want. > > What do you think?

That would be easy to do, but it doesn't solve my underlying problem. What caused me to hit this problem is that Module::Build uses version.pm to parse $VERSION. So a subclass would not help. My code would have to use and depend on a version.pm subclass to declare an integer version. This defeats the point of using an integer version, which is that it's so simple nothing could misinterpret it. -- Don't try the paranormal until you know what's normal. -- "Lords and Ladies" by Terry Prachett

Wed Feb 16 21:56:39 2011 john.peacock [...] havurah-software.org - Correspondence added

Subject:	Re: [rt.cpan.org #65753] Allow "alpha without decimal" versions
Date:	Wed, 16 Feb 2011 21:56:25 -0500
To:	bug-version [...] rt.cpan.org
From:	John Peacock <john.peacock [...] havurah-software.org>

On 02/16/2011 07:51 PM, Michael G Schwern via RT wrote: Show quoted text

> Maybe I miscommunicated. That it's an ISO date is a red herring. The request > is that integer versions be allowed to have an alpha part. > > version->parse("123_45"); > > I don't expect you to do the patching (it wouldn't hurt) but I do need to know > your thoughts on whether 123_45 should be valid. Then I can work up a patch.

OK, that _is_ much clearer. ;-) Show quoted text

> Reading that discussion, I'm not sure how it equates to banning 123_45. Is it > possibly an overzealous restriction?

Some more information can be found here: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00245.html Basically, the INTEGER_ALPHA format cannot be cleanly converted to a v-string and hence cannot be printed with sprintf("%vd",$ver). So that variation was forbidden (without much discussion, I might add). The fact that no one has probably written any code with "%vd" in at least 5 or 6 years, and since version.pm is now in the core (making that construct doubly useless), we could probably lift that restriction. But that discussion needs to happen on p5p probably. Can we just agree to stop imaging that underscores in the $VERSION scalar have any special meaning and just add an ALPHA field to META.YML. Once that exists, M::B, PAUSE, CPAN, and CPANPLUS and the rest of the toolcan can use that instead. John

Wed Feb 16 23:22:34 2011 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #65753] Allow "alpha without decimal" versions
Date:	Thu, 17 Feb 2011 15:22:20 +1100
To:	bug-version [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

On 2011.2.17 1:56 PM, John Peacock via RT wrote: Show quoted text

>> Reading that discussion, I'm not sure how it equates to banning 123_45. Is it >> possibly an overzealous restriction?

> > Some more information can be found here: > > http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00245.html > > Basically, the INTEGER_ALPHA format cannot be cleanly converted to a > v-string and hence cannot be printed with sprintf("%vd",$ver). So that > variation was forbidden (without much discussion, I might add).

If 123.00_45 is ok, could 123_45 be done in the same way? Show quoted text

> The fact that no one has probably written any code with "%vd" in at > least 5 or 6 years, and since version.pm is now in the core (making that > construct doubly useless), we could probably lift that restriction. But > that discussion needs to happen on p5p probably.

Yay... Show quoted text

> Can we just agree to stop imaging that underscores in the $VERSION > scalar have any special meaning and just add an ALPHA field to META.YML. > Once that exists, M::B, PAUSE, CPAN, and CPANPLUS and the rest of the > toolcan can use that instead.

I agree, but that will take a while. META.whatever is just starting to become canonical. OTOH I have a work around (123.00_01) and you're right that the alpha syntax should die. So I'm happy to drop it. -- "Clutter and overload are not an attribute of information, they are failures of design" -- Edward Tufte

Fri Feb 18 06:15:35 2011 john.peacock [...] havurah-software.org - Correspondence added

Subject:	Re: [rt.cpan.org #65753] Allow "alpha without decimal" versions
Date:	Fri, 18 Feb 2011 06:15:25 -0500
To:	bug-version [...] rt.cpan.org
From:	John Peacock <john.peacock [...] havurah-software.org>

On 02/16/2011 11:22 PM, Michael G Schwern via RT wrote: Show quoted text

> If 123.00_45 is ok, could 123_45 be done in the same way?

I'm remembering now the issues: 123.00_45 => 123.0045 123_45 => 12345 Not really the same thing, right? Show quoted text

> So I'm happy to drop it.

Excellent! I'll close the ticket... :D John

Thu Mar 03 08:16:24 2011 jpeacock [...] cpan.org - Correspondence added

WONTFIX. After discussion, we both agreed that using underscores to signify alpha releases is stupid and painful and we don't want to continue to feed that monster...

Thu Mar 03 08:16:35 2011 jpeacock [...] cpan.org - Status changed from 'open' to 'resolved'