Bug #60275 for Math-BaseCnv: bad version

Thu Aug 12 09:57:48 2010 CHORNY [...] cpan.org - Ticket created

Subject:

bad version

I can't install latest XML::Tidy, because version of Math::BaseCnv (which is prereq for it) cannot be determined. Error text: Version '1.6.A6FGHKE' from C:\strawberry\perl\site\lib\Math\BaseCnv.pm does not appear to be valid: BEGIN { q# Hide from _packages_inside() #; package Module::Build::ModuleInfo::_version::p2; use Module::Build::Version; no strict; local $VERSION; $VERSION=undef; $vsub = sub { our $VERSION = '1.6.A6FGHKE'; our $PTVR = $VERSION; $PTVR =~ s/^\d+\.\d+\.//; # Please see `perldoc Time::PT` for an explanation of $PTVR.; $VERSION }; } The fatal error was: Invalid version format (non-numeric data) at C:/strawberry/perl/lib/Module/Build/ModuleInfo.pm line 348, <GEN1> line 17. -- Alexandr Ciornii, http://chorny.net

Fri Aug 13 16:46:49 2010 Pip [...] CPAN.Org - Correspondence added

Hi CHORNY, Sorry you couldn't install my latest modules. I'm terribly fond of my versioning scheme though so I'd ask the Module::Build::ModuleInfo maintainer to accept the initial numeric part of my version numbers && not make it a fatal error when encountering my PipTime non-numeric version field. PAUSE && the CPAN don't have a problem so I don't see why Module::Build should. Maybe it could be made a warning instead of a fatal error? I don't know. I'd like to keep my versions as they are. It's unfortunate that this decision limits my modules availability so severely. I wish the version checkers could be like PAUSE && the CPAN. =( -- -Pip@CPAN.Org

Fri Aug 13 16:46:49 2010 The RT System itself - Status changed from 'new' to 'open'

Sun Jan 09 09:55:27 2011 KENTNL [...] cpan.org - Correspondence added

Its not *just* Module::Build, its really the whole toolchain:

perl -MMath::BaseCnv\ 1.6.A6FGHKE

Invalid version format (non-numeric data) at /usr/lib64/perl5/vendor_perl/5.12.2/Exporter/Heavy.pm line 123.

BEGIN failed--compilation aborted.

perl -MMath::BaseCnv\ 1.6

Invalid version format (non-numeric data).

BEGIN failed--compilation aborted.

perl -MMath::BaseCnv\ 1.5

Invalid version format (non-numeric data).

BEGIN failed--compilation aborted.

perl -MMath::BaseCnv -e 'print $Math::BaseCnv::VERSION'
1.6.A6FGHKE

perl -MMath::BaseCnv -e 'print Math::BaseCnv->VERSION()'

Invalid version format (non-numeric data) at -e line 1.

perl -Mversion -e 'version->parse(q{1.6.A6FGHKE})'
Invalid version format (non-numeric data) at -e line 1.

Whats more, due to this, from upstreams perspective, there is absolutely no way to automatically "normalise" your version form to match our distributions much tigher versioning scheme. We've been currently, by hand, translating your version stuff to a more sensible format, but were' looking to go completely automatic for version normalization, and as such, this version scheme of yours will inspire us to simply refuse to ship your dist instead of having to have somebody manually translate the version.

Sun Jan 09 09:57:55 2011 KENTNL [...] cpan.org - Requestor KENTNL added

Mon Jan 10 17:25:12 2011 PipStuart [...] Gmail.Com - Correspondence added

Subject:	Re: [rt.cpan.org #60275] bad version
Date:	Mon, 10 Jan 2011 16:25:00 -0600
To:	bug-Math-BaseCnv [...] rt.cpan.org
From:	Pip Stuart <pipstuart [...] gmail.com>

Hi Kent, Can't the automatic "normalise" process simply take the beginning Major.Minor version number (/\d+\.\d+/) just like the CPAN && PAUSE do? I really wouldn't ask anyone to convert my complete versions to decimal by hand. Neither do I ask anyone to convert my third component as Base64 or as my Time::PT format (which would be more thorough). I think it perfectly reasonable, however, to ask versions to be treated like they are within the already working && well-established systems of CPAN && PAUSE. In case you could be bothered to understand my attachment to non-numeric version "numbers", my version-strings encode sub-second precision in a time-stamp for the date of release. See HTTP://Search.CPAN.Org/~Pip for my main examples of why I'm reticent on changing my (albeit unconventional) take on versioning && package-naming, etc.. Please, if you would, help me get Module::Build && "really the whole toolchain" to accept at least the prefixed decimal numeric portions of my version formats as valid && sufficient. I'd like my dists to be shipped when possible. Thanks, -Pip On Sun, Jan 9, 2011 at 08:55, Kent Fredric via RT <bug-Math-BaseCnv@rt.cpan.org> wrote: Show quoted text

> Queue: Math-BaseCnv > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=60275 > > > Its not *just* Module::Build, its really the whole toolchain: > > perl -MMath::BaseCnv\ 1.6.A6FGHKE Invalid version format (non-numeric data) at > /usr/lib64/perl5/vendor_perl/5.12.2/Exporter/Heavy.pm line 123.BEGIN > failed--compilation aborted. perl -MMath::BaseCnv\ 1.6Invalid version format > (non-numeric data).BEGIN failed--compilation aborted. > perl -MMath::BaseCnv\ 1.5 > Invalid version format (non-numeric data).BEGIN failed--compilation aborted. > perl -MMath::BaseCnv -e 'print $Math::BaseCnv::VERSION' > 1.6.A6FGHKE > > perl -MMath::BaseCnv -e 'print Math::BaseCnv->VERSION()'Invalid version format > (non-numeric data) at -e line 1. > perl -Mversion -e 'version->parse(q{1.6.A6FGHKE})' > Invalid version format (non-numeric data) at -e line 1. > > Whats more, due to this, from upstreams perspective, there is absolutely no way > to automatically "normalise" your version form to match our distributions much > tigher versioning scheme. We've been currently, by hand, translating your > version stuff to a more sensible format, but were' looking to go completely > automatic for version normalization, and as such, this version scheme of yours > will inspire us to simply refuse to ship your dist instead of having to have > somebody manually translate the version.

Tue Jan 11 14:52:46 2011 KENTNL [...] cpan.org - Correspondence added

I simply don't see what you are trying to achieve with having string data in a version.

If you simply want some sort of reference for when something was released, its better to encode that in the metadata somewhere.

Had perl a way of having 2 versions, one external, and one for "Humans" you could put the ascii in the "Human" one, but the (computer readable) version field is the wrong place for it.

Versions are complicated enough as it is, and adding string-data to them just makes them needlessly *more* complicated.

For some, the string data will be just annotative, and not add any value to the version, for others, it will be expected to be treated as ASCII sort order.

Does A.B mean "A.B00" or A.00B" ?

Having recently had to work with this stuff, I can confess, even simple numeric versions have a large amount of sneakily hidden suck in them, and more complexity in versions is just far far too painful.

And its not "Just Perl" that matters, there are all those Linux distributions, each with their own versioning criteria, and virtually *all* of them completely incompatible with yours.

For lack of a better option, my current solution for Gentoo at least, in order to have something that even slightly corresponds with versioning schemes like your own that is in any way reliable, is to treat the data like an ASCII encoded number of some sorts.

     1.6.A7RJKwl => 1.6.367.991.752.21    ( A7 -> 367, RJ -> 991 , Kw -> KW -> 752, l -> L -> 21 )

This is pretty much the best we can do in terms of automation, because from a downstream perspective, there is no way to differentiate

    1.6.A7RJKwl   # intended as a comment
    1.6.A7RJKwl   # intended as a version

And we must assume that the next logical increment from

    1.6.A7RJKwl

is

     1.6.A7RJKwm

because somebody else will want it so they can do

    1.6a   , 1.6b, 1.6c

or

    1.6.Alpha, 1.6.Beta, 1.6.Gamma

And its pretty much just insanity trying to write *any* code that can handle that all nicely.

Due to the implicit complications that come with permitting ASCII in versions, I'd much *sooner* want PAUSE to *reject* things with non-numeric versions than I would to have the toolchain, and the *whole world* be forced to change how their versioning systems work.

If you want to keep your trailing noise, just keep it out of the places that matter in terms of API conformance:

1. Keep it out of $MY::PACKAGE::VERSION
2. Keep it out of Dist-Name-$version

you can keep stuffing it in your POD I guess, because nothing programming needs that a whole bunch as far as I know, but I may be wrong about that.

And the question is really, do you *need* ascii in your versions? What uses it? what do you have that parses / consumes this data?
We on the contrary, *need* your version to *not* have ascii in it.

If you don't have a reason why you *need* it, then you merely *want* it, and wants tend to be < needs. "wants" are often very irrational =).

Wed Jan 12 11:45:32 2011 PipStuart [...] Gmail.Com - Correspondence added

Subject:	Re: [rt.cpan.org #60275] bad version
Date:	Wed, 12 Jan 2011 10:45:15 -0600
To:	bug-Math-BaseCnv [...] rt.cpan.org
From:	Pip Stuart <pipstuart [...] gmail.com>

Hi Kent, Thanks for the thorough reply. As I wrote earlier: 1.6.A7RJKwl can be simply treated as 1.6 like the CPAN && PAUSE do. The ASCII part can be ignored for simple automated systems. I'd like it if Module::Build && whatever toolchains would basically emulate well-established CPAN behavior, rather than trying to hold module version numbers to some higher standard of validity. I know it's not easy attempting to accommodate the wide variety of peculiar versions though, && my system is certainly on the obtuse end of the scale. I'd still rather not change it, unless the CPAN forces me to at some point. Thanks again. Sincerely, -Pip On Tue, Jan 11, 2011 at 13:52, Kent Fredric via RT <bug-Math-BaseCnv@rt.cpan.org> wrote: Show quoted text

> Queue: Math-BaseCnv > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=60275 > > > I simply don't see what you are trying to achieve with having string data in a > version. > > If you simply want some sort of reference for when something was released, its > better to encode that in the metadata somewhere. > > Had perl a way of having 2 versions, one external, and one for "Humans" you > could put the ascii in the "Human" one, but the (computer readable) version > field is the wrong place for it. > > Versions are complicated enough as it is, and adding string-data to them just > makes them needlessly *more* complicated. > > For some, the string data will be just annotative, and not add any value to the > version, for others, it will be expected to be treated as ASCII sort order. > > Does A.B mean "A.B00" or A.00B" ? > > Having recently had to work with this stuff, I can confess, even simple numeric > versions have a large amount of sneakily hidden suck in them, and more > complexity in versions is just far far too painful. > > And its not "Just Perl" that matters, there are all those Linux distributions, > each with their own versioning criteria, and virtually *all* of them completely > incompatible with yours. > > For lack of a better option, my current solution for Gentoo at least, in order > to have something that even slightly corresponds with versioning schemes like > your own that is in any way reliable, is to treat the data like an ASCII > encoded number of some sorts. > > 1.6.A7RJKwl => 1.6.367.991.752.21 ( A7 -> 367, RJ -> 991 , Kw -> KW -> 752, l > -> L -> 21 ) > > This is pretty much the best we can do in terms of automation, because from a > downstream perspective, there is no way to differentiate > > 1.6.A7RJKwl # intended as a comment > 1.6.A7RJKwl # intended as a version > > And we must assume that the next logical increment from > > 1.6.A7RJKwl > > is > > 1.6.A7RJKwm > > because somebody else will want it so they can do > > 1.6a , 1.6b, 1.6c > > or > > 1.6.Alpha, 1.6.Beta, 1.6.Gamma > > And its pretty much just insanity trying to write *any* code that can handle > that all nicely. > > Due to the implicit complications that come with permitting ASCII in versions, > I'd much *sooner* want PAUSE to *reject* things with non-numeric versions than > I would to have the toolchain, and the *whole world* be forced to change how > their versioning systems work. > > > If you want to keep your trailing noise, just keep it out of the places that > matter in terms of API conformance: > > 1. Keep it out of $MY::PACKAGE::VERSION > 2. Keep it out of Dist-Name-$version > > you can keep stuffing it in your POD I guess, because nothing programming needs > that a whole bunch as far as I know, but I may be wrong about that. > > And the question is really, do you *need* ascii in your versions? What uses it? > what do you have that parses / consumes this data? > We on the contrary, *need* your version to *not* have ascii in it. > > If you don't have a reason why you *need* it, then you merely *want* it, and > wants tend to be < needs. "wants" are often very irrational =). > >

Wed Jan 12 14:35:09 2011 hdp [...] cpan.org - Correspondence added

On Wed Jan 12 11:45:32 2011, PipStuart@Gmail.Com wrote: Show quoted text

> Hi Kent, > > Thanks for the thorough reply. > > As I wrote earlier: > > 1.6.A7RJKwl > > can be simply treated as > > 1.6 > > like the CPAN && PAUSE do.

Perl itself disagrees with PAUSE, as does the rest of the toolchain, making it clear that PAUSE is the outlier here (listing CPAN along with it is redundant -- maybe you meant search.cpan.org, which does something different again, and in any case is a law unto itself). Also, your proposed rule is insufficient -- should e.g. Time::PT 1.2.565EHOV be parsed as 1.2 or as 1.2.565? (You said it should ignore "ASCII", but I think you must have meant "non-numeric", because after all, the numbers are ascii too.) Anyway, your example above suggests 1.2, but that's not what PAUSE does; Time::PT is currently indexed as version 1.002565, not 1.2. The rest of the world isn't going to budge to support your unique scheme, so all you're doing is making it more difficult for people to use your software.

Wed Jan 12 16:23:13 2011 KENTNL [...] cpan.org - Correspondence added

The confusion gets worse:

http://search.cpan.org/~pip/Time-PT-1.2.565EHOV/

seeing:

Time-PT-1.2.565EHOV

and

Time-PT-1.0.42M3ChX

In the same screen, I somehow assumed that it was either

1.0 -> 1.2    where the parts after the . were both 100% ascii

or

1.0.42 -> 1.2.56 , with the "ignored" bit somehow being "5EHOV"

then the confusion worsend when I saw

Time-PT-1.0.3CNNQHc

which proved the first rule was not the case, and you were mixing numerics with non-numerics,

and led me to thinking your "Scheme" implied

1.0.3 -> 1.0.4 -> 1.2.5 with a "Magical" boundary on where to start and stop processing Ascii.

Then I discover "3C193GQ" is a valid Time-PT and all my remaining theories on how it was expected to work went out the window.

So here are 2 things we *cant* do with your scheme:

1. We cant' throw out the entire part after a . that contains non-numeric data and treat the whole part like ignored ASCII, because you release 2 versions where   there is an ignored ascii part and the other parts are otherwise identical.

2. We can't reasonably expect the part after the '.' to even be treatable as a number for the leading parts that are numbers, because they're arbitrary base64 encoded data, and thus, you might do something silly like release 1.0.AAAAAA followed by 1.0.BBBBBBB , which I think you'll agree, cannot be expected to work by "ignoring the Ascii" , because that yields 2 releases with the same version.

3. We can't actually "Just ignore it", because even "ignoring it" is in some way "supporting it". And if we "support it" , more people than *just you* will want to use it ( or expect it to work ). Some will expect it to work like a B64 encoded number, and its obvious, we can't do *BOTH* ignoring the ascii *AND* treating it as a number.

There is no information in your version that indicates "this is just a part that can be ignored" as opposed to "this is information that needs to be handled". Sure, you have said repeatedly, "just ignore it" , but we can't enshrine "Just ignore it" in code that will work on all modules without doing something dumb like enshrining an if ( $cpanid eq 'PIP' ) { do something different }  everywhere in the code. Unless we ignore it for *everyone* , which will turn out to be a bad idea.

We *do* want your contributions to CPAN, and hence the entire reason for us filing bug reports like this one =).

But it is in the best interests of furtherment of this contribution to CPAN for your version to meet the standards of a version that is portable and usable by code.

Wed Nov 02 20:12:57 2011 chromatic [...] cpan.org - Correspondence added

I used Math::BaseCnv in a client project, but the fact that its version number doesn't work with most of the CPAN toolchain is a burden on my client installing the rest of the project. While I can normally say "Run cpanm on this tarball and everything will work," I have three choices now: bundle Math::BaseCnv with the project, reimplement it on my own, or tell my client to install the library manually apart from the toolchain before installing the project. While I'd like to continue using Math::BaseCnv, it seems awfully silly that something as trivial as a version number makes this so difficult. Please consider revising your numbering strategy to follow CPAN community standards.

Sat May 12 17:35:39 2012 perl [...] toby.ink - Correspondence added

I can see how encoding the release time of a distribution into the version number is an attractive idea. But seeing as most of your distributions are in a stable phase (releases months, or even years apart from each other) sub-second precision seems like overkill. Would YYYYMMDD in the version number not suffice? e.g. Math-BaseCnv-2.0.20120512 or: Math-BaseCnv-20120512.20

Wed Sep 25 13:43:46 2013 ether [...] cpan.org - Correspondence added

On 2012-05-12 14:35:39, TOBYINK wrote: Show quoted text

> I can see how encoding the release time of a distribution into the > version number is an attractive idea. But seeing as most of your > distributions are in a stable phase (releases months, or even years apart > from each other) sub-second precision seems like overkill. Would YYYYMMDD > in the version number not suffice? > > e.g. Math-BaseCnv-2.0.20120512 > or: Math-BaseCnv-20120512.20

How would I depend on a particular version of your code, either in my code itself or in metadata? use Math::BaseCnv 1.6; # blows up - non-numeric version WriteMakeFile( ..., PREREQ_PM => { "Math::BaseCnv" => "1.6", # errors out even during 'perl Makefile.PL'!!! }, ); Please read 'perldoc version'. You are violating the standard.

Wed Sep 25 19:02:02 2013 PipStuart [...] Gmail.Com - Correspondence added

Subject:	Re: [rt.cpan.org #60275] bad version
Date:	Wed, 25 Sep 2013 18:01:46 -0500
To:	bug-Math-BaseCnv [...] rt.cpan.org
From:	Pip Stuart <pipstuart [...] gmail.com>

Thank you to everyone who has pointed all this out. I'm sorry for having violated the standard and for remaining largely inaccessible via e-mail. I will make a concerted effort to remedy this version issue prior to any future releases of my CPAN modules. I made a misjudgment when convenience and aesthetics compelled me to introduce base-64 into my versions as strings. I obviously lacked experience, diligence, and foresight to unintentionally drop such a wrench into crucial comparisons. Please forgive me and be patient as I attempt to ready updates. I'm usually mentally blocked and incapable of coding, yet going forward I will try to rectify whatever harm I've done. It also seems fortuitous that Michael Robinton's Math::Base::Convert already routes around my module's failings in a more efficient way. Sincerely, -PipStuart On Wed, Sep 25, 2013 at 12:43 PM, Karen Etheridge via RT < bug-Math-BaseCnv@rt.cpan.org> wrote: Show quoted text

> Queue: Math-BaseCnv > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=60275 > > > On 2012-05-12 14:35:39, TOBYINK wrote:

> > I can see how encoding the release time of a distribution into the > > version number is an attractive idea. But seeing as most of your > > distributions are in a stable phase (releases months, or even years apart > > from each other) sub-second precision seems like overkill. Would YYYYMMDD > > in the version number not suffice? > > > > e.g. Math-BaseCnv-2.0.20120512 > > or: Math-BaseCnv-20120512.20

> > How would I depend on a particular version of your code, either in my code > itself or in metadata? > > use Math::BaseCnv 1.6; # blows up - non-numeric version > > WriteMakeFile( > ..., > PREREQ_PM => { > "Math::BaseCnv" => "1.6", # errors out even during 'perl > Makefile.PL'!!! > }, > ); > > Please read 'perldoc version'. You are violating the standard. >

Sat Jun 17 20:19:55 2017 Pip [...] CPAN.Org - Taken

Sat Jun 17 20:23:20 2017 Pip [...] CPAN.Org - Status changed from 'open' to 'resolved'

Sat Jun 17 20:23:31 2017 Pip [...] CPAN.Org - Fixed in 1.10 added