Skip Menu |
 

This queue is for tickets about the Math-BaseCnv CPAN distribution.

Report information
The Basics
Id: 60275
Status: resolved
Priority: 0/
Queue: Math-BaseCnv

People
Owner: Pip [...] CPAN.Org
Requestors: CHORNY [...] cpan.org
KENTNL [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 1.6.A6FGHKE
Fixed in: 1.10



Subject: bad version
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 799
Download (untitled) / with headers
text/plain 799b
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
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-11057-1281732409-574.60275-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 657
Download (untitled) / with headers
text/plain 657b
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
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-11057-1281732409-574.60275-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-11057-1281732409-574.60275-0-0 [...] rt.cpan.org>
Content-Type: text/html; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-9726-1294584927-774.60275-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 1529
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. 

From pipstuart [...] gmail.com Mon Jan 10 17: 25:11 2011
MIME-Version: 1.0
X-Spam-Status: No, score=-8.062 tagged_above=-99.9 required=10 tests=[AWL=-1.852, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779, T_TO_NO_BRKTS_FREEMAIL=0.01] autolearn=ham
In-Reply-To: <rt-3.8.HEAD-9726-1294584927-145.60275-5-0 [...] rt.cpan.org>
X-Spam-Flag: NO
References: <RT-Ticket-60275 [...] rt.cpan.org> <rt-3.8.HEAD-11057-1281732409-574.60275-5-0 [...] rt.cpan.org> <rt-3.8.HEAD-9726-1294584927-145.60275-5-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Reply-To: PipStuart [...] GMail.Com
Message-ID: <AANLkTi=Ak2SuZ-HAK7NNCFTmBL_WbVtBy+1hzeuyZFzE [...] mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
X-RT-Original-Encoding: utf-8
X-Spam-Score: -8.062
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Authentication-Results: hipster.bestpractical.com (amavisd-new); domainkeys=pass header.from=pipstuart [...] gmail.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 2B5AF2413B1 for <cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com>; Mon, 10 Jan 2011 17:25:11 -0500 (EST)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gfLu8EWlE0G for <cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com>; Mon, 10 Jan 2011 17:25:08 -0500 (EST)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 703F52413AC for <bug-Math-BaseCnv [...] rt.cpan.org>; Mon, 10 Jan 2011 17:25:08 -0500 (EST)
Received: (qmail 21766 invoked by uid 103); 10 Jan 2011 22:25:07 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 10 Jan 2011 22:25:07 -0000
Received: from mail-ww0-f52.google.com (HELO mail-ww0-f52.google.com) (74.125.82.52) by 16.mx.develooper.com (qpsmtpd/0.80) with ESMTP; Mon, 10 Jan 2011 14:25:04 -0800
Received: by wwd20 with SMTP id 20so21559223wwd.21 for <bug-Math-BaseCnv [...] rt.cpan.org>; Mon, 10 Jan 2011 14:25:01 -0800 (PST)
Received: by 10.227.182.13 with SMTP id ca13mr3266185wbb.180.1294698300743; Mon, 10 Jan 2011 14:25:00 -0800 (PST)
Received: by 10.227.156.2 with HTTP; Mon, 10 Jan 2011 14:25:00 -0800 (PST)
Delivered-To: cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #60275] bad version
Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=oB/QKSvIzk9PNpSX9TNEinTCY65268hJw0e6Pbjsy8Bdia16C4ABW1rLtzd15YJFp1 +lR1wwd3HD/dj+ILtn90vaYPLWzvOAWz07q0lRb4wtvrARTsqgFtNuKtXMV4GstfcDEA STZ95A3QUNUkqsnLfQu25lZdQCKH3xilc5Gws=
Return-Path: <pipstuart [...] gmail.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=m06UT+Yz6SvSwkdEyOqapbGclqS6FarvodJtya53xcg=; b=emOveUfYpZFn3eX5CIRYY4pVJ2mql2/yV3xwA2yrdjIarLTT6Ir7CAuDaUVv4Tb9Gf SgjaBCiz7FI4KiOzHtwpXTpLqvEmvkKQ9LXHZpJFDQCPNEXOo7Y4prJ86DO/7C4Lq0tM jdMWIervdMnJTefSrETP9hsPIvrf4RG/NQ1rI=
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com
X-RT-Mail-Extension: math-basecnv
Date: Mon, 10 Jan 2011 16:25:00 -0600
X-Spam-Level:
To: bug-Math-BaseCnv [...] rt.cpan.org
Content-Transfer-Encoding: quoted-printable
From: Pip Stuart <pipstuart [...] gmail.com>
RT-Message-ID: <rt-3.8.HEAD-9726-1294698312-1819.60275-0-0 [...] rt.cpan.org>
Content-Length: 2564
Download (untitled) / with headers
text/plain 2.5k
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.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/html; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-19315-1294775566-123.60275-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 3714
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  =).


From pipstuart [...] gmail.com Wed Jan 12 11: 45:32 2011
MIME-Version: 1.0
X-Spam-Status: No, score=-7.444 tagged_above=-99.9 required=10 tests=[AWL=-1.234, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779, T_TO_NO_BRKTS_FREEMAIL=0.01] autolearn=ham
In-Reply-To: <rt-3.8.HEAD-19315-1294775567-681.60275-5-0 [...] rt.cpan.org>
X-Spam-Flag: NO
References: <RT-Ticket-60275 [...] rt.cpan.org> <rt-3.8.HEAD-19315-1294775567-681.60275-5-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Reply-To: PipStuart [...] GMail.Com
Message-ID: <AANLkTikrfMTp=dTdAYX+3GQxUrtyW0_CkXxbcAyA1zmD [...] mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
X-RT-Original-Encoding: utf-8
X-Spam-Score: -7.444
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Authentication-Results: hipster.bestpractical.com (amavisd-new); domainkeys=pass header.from=pipstuart [...] gmail.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 11D7724140D for <cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com>; Wed, 12 Jan 2011 11:45:32 -0500 (EST)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEWVeMqGwXnX for <cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com>; Wed, 12 Jan 2011 11:45:30 -0500 (EST)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id B2F9A2412E4 for <bug-Math-BaseCnv [...] rt.cpan.org>; Wed, 12 Jan 2011 11:45:29 -0500 (EST)
Received: (qmail 20532 invoked by uid 103); 12 Jan 2011 16:45:29 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 12 Jan 2011 16:45:29 -0000
Received: from mail-wy0-f178.google.com (HELO mail-wy0-f178.google.com) (74.125.82.178) by 16.mx.develooper.com (qpsmtpd/0.80) with ESMTP; Wed, 12 Jan 2011 08:45:19 -0800
Received: by wyb42 with SMTP id 42so797233wyb.9 for <bug-Math-BaseCnv [...] rt.cpan.org>; Wed, 12 Jan 2011 08:45:15 -0800 (PST)
Received: by 10.227.154.204 with SMTP id p12mr1237036wbw.6.1294850715469; Wed, 12 Jan 2011 08:45:15 -0800 (PST)
Received: by 10.227.156.2 with HTTP; Wed, 12 Jan 2011 08:45:15 -0800 (PST)
Delivered-To: cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #60275] bad version
Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=TBZvgzeij+x+GTLMBbZj4aDkUD/i2wTLpEtYry8lwBaSO2a/WsUTEGm4Vk5aR1FXFv 3A8CqKXTWiFBzvYfw33wp5dPEflkmuUrQQSE5ezP+YDzZiGgR0IS+eDguyw/jriCgijR at2RBOcT9JCTkEmKVPR54xalu3aYuOn9X6wxc=
Return-Path: <pipstuart [...] gmail.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=jc7CsgtLzEmndQl93qX3X8NpBUiLLQC8thH+eusajbc=; b=lvsp7E6+9jRQkdGfRof5P/u77mSyZmHehLg6ltHPZyJx4Fuv0Th7C4ZR0YEKqxqJ5Y 4FkhsGE43bEodysp2e/yd+re72JVi0XO9jOrMaOcpKYlw/UrQRlyeH/mLVmNoZibnqKV E55dLvh1WM8OjiE1ZjmqmRbEic9Qb+o12R33o=
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com
X-RT-Mail-Extension: math-basecnv
Date: Wed, 12 Jan 2011 10:45:15 -0600
X-Spam-Level:
To: bug-Math-BaseCnv [...] rt.cpan.org
Content-Transfer-Encoding: quoted-printable
From: Pip Stuart <pipstuart [...] gmail.com>
RT-Message-ID: <rt-3.8.HEAD-17549-1294850732-290.60275-0-0 [...] rt.cpan.org>
Content-Length: 3881
Download (untitled) / with headers
text/plain 3.7k
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 =). > >
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-17549-1294850732-290.60275-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <RT-Ticket-60275 [...] rt.cpan.org> <rt-3.8.HEAD-19315-1294775567-681.60275-5-0 [...] rt.cpan.org> <AANLkTikrfMTp=dTdAYX+3GQxUrtyW0_CkXxbcAyA1zmD [...] mail.gmail.com> <rt-3.8.HEAD-17549-1294850732-290.60275-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-17550-1294860909-1843.60275-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 1017
Download (untitled) / with headers
text/plain 1017b
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.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-17550-1294860909-1843.60275-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <RT-Ticket-60275 [...] rt.cpan.org> <rt-3.8.HEAD-19315-1294775567-681.60275-5-0 [...] rt.cpan.org> <AANLkTikrfMTp=dTdAYX+3GQxUrtyW0_CkXxbcAyA1zmD [...] mail.gmail.com> <rt-3.8.HEAD-17549-1294850732-290.60275-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-17550-1294860909-1843.60275-0-0 [...] rt.cpan.org>
Content-Type: text/html; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-17551-1294867393-226.60275-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 3243
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.
 


MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-2599-1320279177-224.60275-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 689
Download (untitled) / with headers
text/plain 689b
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.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-20178-1336858539-726.60275-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 380
Download (untitled) / with headers
text/plain 380b
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
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-20178-1336858539-726.60275-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-3.8.HEAD-20178-1336858539-726.60275-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.16-836-1380131026-893.60275-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 821
Download (untitled) / with headers
text/plain 821b
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.
From pipstuart [...] gmail.com Wed Sep 25 19: 02:01 2013
MIME-Version: 1.0
X-Spam-Status: No, score=-6.333 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
In-Reply-To: <rt-4.0.16-836-1380131026-729.60275-5-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-60275 [...] rt.cpan.org> <rt-3.8.HEAD-20178-1336858539-726.60275-5-0 [...] rt.cpan.org> <rt-4.0.16-836-1380131026-729.60275-5-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Received: by 10.112.155.39 with SMTP id vt7mr1246003lbb.29.1380150106475; Wed, 25 Sep 2013 16:01:46 -0700 (PDT)
Reply-To: PipStuart [...] GMail.Com
Message-ID: <CAEv=-x3dsE+n3h9hmsxxpwC1C0OYdaN+WNW+6Wki4b4ON1dVgQ [...] mail.gmail.com>
Content-Type: multipart/alternative; boundary="089e0112c136d552d604e73d3cf0"
X-Spam-Score: -6.333
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 5870A2407C1 for <cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com>; Wed, 25 Sep 2013 19:02:01 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAYfCxsM4t8H for <cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com>; Wed, 25 Sep 2013 19:01:58 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id C9993240701 for <bug-Math-BaseCnv [...] rt.cpan.org>; Wed, 25 Sep 2013 19:01:57 -0400 (EDT)
Received: (qmail 4099 invoked by alias); 25 Sep 2013 23:01:56 -0000
Received: from mail-la0-f44.google.com (HELO mail-la0-f44.google.com) (209.85.215.44) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Wed, 25 Sep 2013 16:01:51 -0700
Received: by mail-la0-f44.google.com with SMTP id eo20so294364lab.3 for <bug-Math-BaseCnv [...] rt.cpan.org>; Wed, 25 Sep 2013 16:01:46 -0700 (PDT)
Received: by 10.114.81.36 with HTTP; Wed, 25 Sep 2013 16:01:46 -0700 (PDT)
Delivered-To: cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #60275] bad version
Return-Path: <pipstuart [...] gmail.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=ZakKE6rfIXaYsqnv/vvamPCZ5PGxBThaJCHRmRIOaIY=; b=zBfA9Z323kXeVMxUh+o3w6AJTuRmf8kvJQIDcfQiFQ7ugrwf8QjPBdHY/5OCnAdptw B1aPRjBESyCFZ5ckdqx8iIY92UbrNIJBh3qz0g4ajtFAvNGgtwpukc744aGmt9+LF4n4 TMVdbz7oFdFGrjihB9cjyLnGTLqEH4nbmDBB7hF/XoJwPZJ/iF7jbkOwhI49jIO6gQPP mlgHgaXaUZNb1Y8noTOcYrab4ojMqAGqMgzNf5YmdVB12K3AWQfWGOEqld7DM8kgmejh o0HMrn23fLfq1OE+whaZLoxom/XO+v2L23r4lJ0oSIYaH/m+7wPqcI16OpdPuqzNta1O A9aQ==
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+Math-BaseCnv [...] hipster.bestpractical.com
X-RT-Mail-Extension: math-basecnv
Date: Wed, 25 Sep 2013 18:01:46 -0500
X-Spam-Level:
To: bug-Math-BaseCnv [...] rt.cpan.org
From: Pip Stuart <pipstuart [...] gmail.com>
RT-Message-ID: <rt-4.0.16-16114-1380150122-1488.60275-0-0 [...] rt.cpan.org>
Content-Length: 0
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Content-Length: 1895
Download (untitled) / with headers
text/plain 1.8k
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. >
content-type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Content-Length: 2601


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.