FAQ
Elliot just alerted me to this bit of the v2 spec.

http://search.cpan.org/~dagolden/CPAN-Meta-2.101091/lib/CPAN/Meta/Spec.pm#Version_Formats

Dotted-integer versions
"All components after the first are restricted to the range 0 to 999."

Why have a limit on a simple integer, and such a low one? I did this in the
distant past with MakeMaker and was roundly, and justly, admonished.


--
44. I am not the atheist chaplain.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/

Search Discussions

  • Steffen Mueller at Apr 19, 2010 at 12:14 pm

    Michael G Schwern wrote:
    Elliot just alerted me to this bit of the v2 spec.

    http://search.cpan.org/~dagolden/CPAN-Meta-2.101091/lib/CPAN/Meta/Spec.pm#Version_Formats


    Dotted-integer versions
    "All components after the first are restricted to the range 0 to 999."

    Why have a limit on a simple integer, and such a low one? I did this in
    the distant past with MakeMaker and was roundly, and justly, admonished.
    IIRC it's because the magic XXXXXXXX.YYY.ZZZ <-> XXXXXXXX.YYYZZZ
    association is assumed all over the place.

    Note that XXXXX can be way beyond 999.

    Cheers,
    Steffen
  • Michael G Schwern at Apr 19, 2010 at 12:45 pm

    Steffen Mueller wrote:
    Why have a limit on a simple integer, and such a low one? I did this
    in the distant past with MakeMaker and was roundly, and justly,
    admonished.
    IIRC it's because the magic XXXXXXXX.YYY.ZZZ <-> XXXXXXXX.YYYZZZ
    association is assumed all over the place.
    I was worried that was it. That conversion should be considered, but not
    enshrined in the spec as a limit.

    As noted earlier, the spec is missing a definition about how versions compare.
    Using the conversion algorithm I outlined to convert from decimal to dotted,
    which appears to be what version.pm uses, there's no need for a limit.
    vX.YYYY is always greater than X.anything because you can't express vX.YYYY as
    a dotted version. And that's fine, there's no requirement for a one to one
    mapping. So long as every decimal can be expressed as a dotted everything can
    be compared.
  • David Golden at Apr 19, 2010 at 1:03 pm

    On Mon, Apr 19, 2010 at 8:45 AM, Michael G Schwern wrote:
    Steffen Mueller wrote:
    Why have a limit on a simple integer, and such a low one?  I did this in
    the distant past with MakeMaker and was roundly, and justly, admonished.
    IIRC it's because the magic XXXXXXXX.YYY.ZZZ <-> XXXXXXXX.YYYZZZ
    association is assumed all over the place.
    I was worried that was it.  That conversion should be considered, but not
    enshrined in the spec as a limit.
    Please see my response on the module-authors list. The issue isn't
    decimal to dotted decimal, it's the reverse mapping which is done
    inconsistently.

    -- David
  • Michael G Schwern at Apr 19, 2010 at 1:50 pm

    David Golden wrote:
    On Mon, Apr 19, 2010 at 8:45 AM, Michael G Schwern wrote:
    Steffen Mueller wrote:
    Why have a limit on a simple integer, and such a low one? I did this in
    the distant past with MakeMaker and was roundly, and justly, admonished.
    IIRC it's because the magic XXXXXXXX.YYY.ZZZ <-> XXXXXXXX.YYYZZZ
    association is assumed all over the place.
    I was worried that was it. That conversion should be considered, but not
    enshrined in the spec as a limit.
    Please see my response on the module-authors list. The issue isn't
    decimal to dotted decimal, it's the reverse mapping which is done
    inconsistently.
    Do we need every dotted version to have a decimal representation? Or is it
    simply enough that they compare fine?

    You mention "not all parts of the toolchain support prerequisites specified in
    dotted decimal form." That would be the rationale, but what's left that doesn't?


    --
    Don't try the paranormal until you know what's normal.
    -- "Lords and Ladies" by Terry Prachett
  • Adam Kennedy at Apr 19, 2010 at 2:04 pm
    Other than stuff that predates our ability to force the toolchain
    modules to be updated, obviously...

    Adam K
    On Mon, Apr 19, 2010 at 11:50 PM, Michael G Schwern wrote:
    David Golden wrote:
    On Mon, Apr 19, 2010 at 8:45 AM, Michael G Schwern <schwern@pobox.com>
    wrote:
    Steffen Mueller wrote:
    Why have a limit on a simple integer, and such a low one?  I did this
    in
    the distant past with MakeMaker and was roundly, and justly,
    admonished.
    IIRC it's because the magic XXXXXXXX.YYY.ZZZ <-> XXXXXXXX.YYYZZZ
    association is assumed all over the place.
    I was worried that was it.  That conversion should be considered, but not
    enshrined in the spec as a limit.
    Please see my response on the module-authors list.  The issue isn't
    decimal to dotted decimal, it's the reverse mapping which is done
    inconsistently.
    Do we need every dotted version to have a decimal representation?  Or is it
    simply enough that they compare fine?

    You mention "not all parts of the toolchain support prerequisites specified
    in dotted decimal form."  That would be the rationale, but what's left that
    doesn't?


    --
    Don't try the paranormal until you know what's normal.
    -- "Lords and Ladies" by Terry Prachett
  • David Golden at Apr 19, 2010 at 7:30 pm

    On Mon, Apr 19, 2010 at 9:50 AM, Michael G Schwern wrote:
    Do we need every dotted version to have a decimal representation?  Or is it
    simply enough that they compare fine?

    You mention "not all parts of the toolchain support prerequisites specified
    in dotted decimal form."  That would be the rationale, but what's left that
    doesn't?
    Perl itself, for one. I refer you to
    http://www.dagolden.com/index.php/204/perl-version-number-puzzles/ for
    your horror and amusement.

    The Perl community has so horribly screwed up module version numbering
    that the spec just attempts to encourage a minimum level of
    consistency. It can't solve all the problems.

    -- David
  • Eric Wilhelm at Apr 19, 2010 at 11:07 pm
    # from David Golden
    # on Monday 19 April 2010 12:29:
    You mention "not all parts of the toolchain support prerequisites
    specified in dotted decimal form."  That would be the rationale, but
    what's left that doesn't?
    Perl itself, for one.  I refer you to
    http://www.dagolden.com/index.php/204/perl-version-number-puzzles/ for
    your horror and amusement.
    Did that demonstrate a case where you must convert from float to
    multi-dotted and back, but I just missed it?
    The Perl community has so horribly screwed up module version numbering
    ...mostly by trying to treat them as a float, IMO.
    that the spec just attempts to encourage a minimum level of
    consistency. It can't solve all the problems.
    The spec and the tools are different things. The tools are broken and
    buggy junk which nobody has upgraded in 10 years and thus they won't be
    impacted by this or any future spec.
    I was worried that was it. That conversion should be considered,
    but not enshrined in the spec as a limit.
    +1 +999

    --Eric
    --
    "It is a mistake to allow any mechanical object to realize that you are
    in a hurry."
    --Ralph's Observation
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • Adam Kennedy at Apr 19, 2010 at 11:49 pm

    I was worried that was it.  That conversion should be considered,
    but not enshrined in the spec as a limit.
    "999 revisions ought to be enough to anyone"
  • Michael G Schwern at Apr 21, 2010 at 11:47 am

    David Golden said:
    Perl itself, for one. I refer you to
    http://www.dagolden.com/index.php/204/perl-version-number-puzzles/ for
    your horror and amusement.
    Those are interesting, but I'm not entirely sure how they practically relate.
    A module requiring version vX.Y.Z isn't likely to generate "use Foo vX.Y.Z"
    code! I can't even reproduce most of them. I suspect they're related to
    broken versions of version.pm (which questions, again, the wisdom of pinning
    the spec to version.pm).

    The Perl community has so horribly screwed up module version numbering
    that the spec just attempts to encourage a minimum level of
    consistency. It can't solve all the problems.
    If this is all about supporting out of date Perls and toolchains, can we
    downgrade it to a recommendation/should rather than a must? It seems silly to
    declare a meta file invalid just to support some dying edge cases.

    On 2010.4.20 2:49 AM, Adam Kennedy wrote:
    I was worried that was it. That conversion should be considered,
    but not enshrined in the spec as a limit.
    "999 revisions ought to be enough to anyone"
    ♪ I got 999 revisions but I can't add one ♪

    I speak from experience, limiting the version is a bad idea.

    http://markmail.org/message/ra4wobbbyk5nx36a

    http://groups.google.com/group/perl.perl5.porters/browse_thread/thread/722c95dc76480dd1/bea6e5897fcbd584?q=#bea6e5897fcbd584


    --
    40. I do not have super-powers.
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
    http://skippyslist.com/list/
  • Jarkko Hietaniemi at Apr 21, 2010 at 12:19 pm

    "999 revisions ought to be enough to anyone"
    ♪ I got 999 revisions but I can't add one ♪

    I speak from experience, limiting the version is a bad idea.
    Some people version their modules with YYYYMMDD. I can see
    bleeding edge development going with added HHHMMSS.
  • David Golden at Apr 21, 2010 at 12:42 pm

    On Wed, Apr 21, 2010 at 7:47 AM, Michael G Schwern wrote:
    If this is all about supporting out of date Perls and toolchains, can we
    downgrade it to a recommendation/should rather than a must?  It seems silly to
    declare a meta file invalid just to support some dying edge cases.
    I'm willing to call it a "should" and do a "typo fix" in the spec.
    (As long as you promise to actually *read* things when I ask for
    review *before* I release them.)

    Any opposed?

    -- David

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedApr 19, '10 at 11:59a
activeApr 21, '10 at 12:42p
posts12
users6
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase