FAQ
04. Formalize allowed version number formats

Proposal:

Formalize the spec for version numbers as "decimal or normalized
dotted-integer (leading "v" and at least 3 components). (Dagolden)

Comments:

* It's not clear whether/how to include alpha versions (with underscores)
in the spec as they generally cannot be resolved by the toolchain
(Dagolden)

* Version comparison for "greater than" must be both possible and fully
described in all possible combinations, as things like Module::Install
need to handle duplicate dependency assertions. For example, part of the
M:I internals silently assert "requires File::ShareDir 1.23". If the user
then manually asserts "requires File::ShareDir v1.24.1" M:I needs to be
able to determine which to keep and which to discard.
(AdamKennedy)

* SUPER 1.16 declares some dependencies as the empty string instead of
zero. This apparently causes problems for some part of the toolchain.
We should clarify that empty string (and undef) are not allowed. I
believe the toolchain special cases 0 to mean "any" even if a module does
not define $VERSION, but we should specify that behavior explicitly as
well. (Dagolden)

Search Discussions

  • Ricardo Signes at Oct 9, 2009 at 12:12 pm
    * David Golden [2009-10-09T07:43:00]
    04. Formalize allowed version number formats

    Proposal:

    Formalize the spec for version numbers as "decimal or normalized
    dotted-integer (leading "v" and at least 3 components). (Dagolden)
    Agree. (Wording should be very clear, with examples, in the spec.)

    --
    rjbs
  • Graham Barr at Oct 9, 2009 at 1:28 pm

    On Oct 9, 2009, at 7:12 AM, Ricardo Signes wrote:

    * David Golden [2009-10-09T07:43:00]
    04. Formalize allowed version number formats

    Proposal:

    Formalize the spec for version numbers as "decimal or normalized
    dotted-integer (leading "v" and at least 3 components). (Dagolden)
    Agree. (Wording should be very clear, with examples, in the spec.)
    +1

    Graham.
  • Steffen Mueller at Oct 9, 2009 at 2:05 pm

    Ricardo Signes wrote:
    * David Golden [2009-10-09T07:43:00]
    04. Formalize allowed version number formats

    Proposal:

    Formalize the spec for version numbers as "decimal or normalized
    dotted-integer (leading "v" and at least 3 components). (Dagolden)
    Agree. (Wording should be very clear, with examples, in the spec.)
    I have no doubts that this is a crucial step forward.

    Steffen
  • David Golden at Oct 9, 2009 at 1:48 pm

    On Fri, Oct 9, 2009 at 7:43 AM, David Golden wrote:
    04. Formalize allowed version number formats

    Proposal:

    Formalize the spec for version numbers as "decimal or normalized
    dotted-integer (leading "v" and at least 3 components).  (Dagolden)

    Comments:

    * It's not clear whether/how to include alpha versions (with underscores)
    in the spec as they generally cannot be resolved by the toolchain
    (Dagolden)
    I have mixed feelings about this still. I'd like to rely on
    version.pm's normalization so we don't re-implement it, but I really
    don't like it's alpha comparison logic. I think alpha's should
    compare "numerically" without regard for alpha status, which is really
    just distribution-level meta information about whether it should be
    indexed or not.

    Disallowing underscores in META would be a way to enforce this, but
    then comparing version in META and version in $VERSION is harder.
    * Version comparison for "greater than" must be both possible and fully
    described in all possible combinations, as things like Module::Install
    need to handle duplicate dependency assertions. For example, part of the
    M:I internals silently assert "requires File::ShareDir 1.23". If the user
    then manually asserts "requires File::ShareDir v1.24.1" M:I needs to be
    able to determine which to keep and which to discard.
    (AdamKennedy)
    I agree in principle, but I disagree on "all possible combinations".
    We shouldn't try to specify heuristics to deal with the ways people
    screw up version numbering. (e.g. 1.23 => v1.230.0 which is greater
    than v1.24.1). As long as we specify dotted-tuple-with-leading-v or
    decimal as allowed formats, we know how to compare those
    (notwithstanding 64-bit precision decimal conversion bugs). Dotted
    tuple without leading v we can assume to be a badly formatted tuple
    and we can be liberal. (*must* emit strict to spec, *may*/*should*
    interpret 1.2.3 as v1.2.3)

    -- David
  • Barbie at Oct 31, 2009 at 3:53 pm

    On Fri, Oct 09, 2009 at 09:48:17AM -0400, David Golden wrote:
    On Fri, Oct 9, 2009 at 7:43 AM, David Golden wrote:
    04. Formalize allowed version number formats

    Proposal:

    Formalize the spec for version numbers as "decimal or normalized
    dotted-integer (leading "v" and at least 3 components).  (Dagolden)

    Comments:

    * It's not clear whether/how to include alpha versions (with underscores)
    in the spec as they generally cannot be resolved by the toolchain
    (Dagolden)
    I have mixed feelings about this still. I'd like to rely on
    version.pm's normalization so we don't re-implement it, but I really
    don't like it's alpha comparison logic. I think alpha's should
    compare "numerically" without regard for alpha status, which is really
    just distribution-level meta information about whether it should be
    indexed or not.

    Disallowing underscores in META would be a way to enforce this, but
    then comparing version in META and version in $VERSION is harder.
    Agreed that this needs to be made clear, but I think disallowing
    underscores may cause more problems than it's worth.
    * Version comparison for "greater than" must be both possible and fully
    described in all possible combinations, as things like Module::Install
    need to handle duplicate dependency assertions. For example, part of the
    M:I internals silently assert "requires File::ShareDir 1.23". If the user
    then manually asserts "requires File::ShareDir v1.24.1" M:I needs to be
    able to determine which to keep and which to discard.
    (AdamKennedy)
    I agree in principle, but I disagree on "all possible combinations".
    We shouldn't try to specify heuristics to deal with the ways people
    screw up version numbering. (e.g. 1.23 => v1.230.0 which is greater
    than v1.24.1). As long as we specify dotted-tuple-with-leading-v or
    decimal as allowed formats, we know how to compare those
    (notwithstanding 64-bit precision decimal conversion bugs). Dotted
    tuple without leading v we can assume to be a badly formatted tuple
    and we can be liberal. (*must* emit strict to spec, *may*/*should*
    interpret 1.2.3 as v1.2.3)
    We should make it clear what version formats are acceptable, and in the
    event of any possible ambiguity, what will be assumed.

    Cheers,
    Barbie.
    --
    Birmingham Perl Mongers <http://birmingham.pm.org>
    Memoirs Of A Roadie <http://barbie.missbarbell.co.uk>
    CPAN Testers Blog <http://blog.cpantesters.org>
    YAPC Conference Surveys <http://yapc-surveys.org>
  • David Golden at Oct 31, 2009 at 7:21 pm

    On Sat, Oct 31, 2009 at 11:53 AM, Barbie wrote:
    Disallowing underscores in META would be a way to enforce this, but
    then comparing version in META and version in $VERSION is harder.
    Agreed that this needs to be made clear, but I think disallowing
    underscores may cause more problems than it's worth.
    Disallowing makes it worse. Here's why:

    $ perl -Mversion -E 'say version->new("1.23_45") <=> version->new("1.2345")'
    -1

    If the first form is specified in an installed *.pm file (as parsed
    with MM->parse_version), but the second is in the META file, then the
    META requirement can't be satisfied by the installed file. We *must*
    allow underscore. The branch I've created is specific in that we only
    allow a single underscore, though, and for v-strings, only for the
    last component.
    We should make it clear what version formats are acceptable, and in the
    event of any possible ambiguity, what will be assumed.
    Hmm. I don't want to specify what will be assumed or else that
    becomes defacto acceptable. The likely reality is that what will be
    assumed is whatever version.pm does.

    -- David
  • Chris Weyl at Oct 11, 2009 at 6:18 pm
    Just to leap in here...
    04. Formalize allowed version number formats

    Proposal:

    Formalize the spec for version numbers as "decimal or normalized
    dotted-integer (leading "v" and at least 3 components). (Dagolden)
    As someone who maintains a ridiculous number of CPAN packages as RPMs
    in a linux distro (Fedora), I've been struggling with ideas of how to
    keep our packaged versions in sync with the latest released levels on
    the CPAN -- and beyond that, how to make automatic processes to do
    this require less of my time/brainpower. One of the recurring
    problems to this is the rather free-form approach that can be taken
    with module versions and how this translates to versioning RPM knows
    and understands. These two things are, ah, not always the one and the
    same.

    Having a regularized versioning scheme (inside the metadata at the
    least) that external packaging systems can leverage would help reduce
    the number of manual interventions required of packagers to maintain
    CPAN packages in a binary distro (Fedora/RPM or otherwise), and in
    general make dep solving significantly more reliable than it is today.
    If my vote counts, I'm all for this.

    Just my $0.02USD :)

    -Chris
    --
    Chris Weyl
    Ex astris, scientia
  • David Golden at Oct 31, 2009 at 12:11 pm

    On Fri, Oct 9, 2009 at 7:43 AM, David Golden wrote:
    04. Formalize allowed version number formats

    Proposal:

    Formalize the spec for version numbers as "decimal or normalized
    dotted-integer (leading "v" and at least 3 components).  (Dagolden)

    Comments:

    * It's not clear whether/how to include alpha versions (with underscores)
    in the spec as they generally cannot be resolved by the toolchain
    (Dagolden)

    * Version comparison for "greater than" must be both possible and fully
    described in all possible combinations, as things like Module::Install
    need to handle duplicate dependency assertions. For example, part of the
    M:I internals silently assert "requires File::ShareDir 1.23". If the user
    then manually asserts "requires File::ShareDir v1.24.1" M:I needs to be
    able to determine which to keep and which to discard.
    (AdamKennedy)

    * SUPER 1.16 declares some dependencies as the empty string instead of
    zero.  This apparently causes problems for some part of the toolchain.
    We should clarify that empty string (and undef) are not allowed.  I
    believe the toolchain special cases 0 to mean "any" even if a module does
    not define $VERSION, but we should specify that behavior explicitly as
    well.  (Dagolden)
    First draft patch here. Still needs more work:

    http://github.com/dagolden/cpan-meta-spec/tree/04-version-formats

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedOct 9, '09 at 11:43a
activeOct 31, '09 at 7:21p
posts9
users6
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase