David Golden wrote:
> On Sat, Apr 18, 2009 at 2:26 PM, Michael G Schwern <[email protected]> wrote:
>> vX.Y dotted pair?
>
> vX.Y is a dotted pair, as per version.pm anyway.
>
>> And how do you compare them all together? You have to pull in a module just
>
> At least it's a detail that toolchain developers need to know about
> and hopefully can hide from end-users. (Authors *ought* to know, but
> it's clear they don't even read the docs of version.pm when they use
> it.)
This assumes Perl toolchain devs are the only ones who need to deal with it.
That assumption doesn't hold true for META.yml. It's designed as a protocol
to avoid having to know special magic parsing. I think you've taken a very
narrow view of who may use META.yml and its colored your logic.
As for authors, version.pm was touted as the best way to handle versioning and
its turned out to be a minefield. They shouldn't have to study documentation
to WRITE A VERSION NUMBER! I can't blame the authors here.
>> Part of the point of META.yml is to make it easier to get metadata about a
>> package. No more scraping around in $VERSION or special parsing logic or
>> guessing. This reintroduces special parsing logic. To this end, the
>> META.yml
>> version should be normalized to a simple decimal. use version->numify.
>
> That's not a good idea because it doesn't deal the wide variety of
> distribution version schemes already on CPAN. Like it or not, they
> exist and we need to accommodate them.
I think you've crossed the streams here. The issue of whether we still need
to parse out $VERSION vs using META.yml is orthogonal. META.yml should still
strive to remain simple.
> Let's be very, very clear here. There are *two* types of version
> numbers that can show up in META.yml:
>
> (1) Distribution version (the "version" key)
>
> (2) Module version in the "provides" section.
>
> (OK, technically, there are prereqs version numbers, but I'm talking
> about numbers generated for the META.yml for the distribution
> containing it.)
>
> Distribution version numbers have absolutely no meaning except to
> associate a META.yml with a file on CPAN:
> PAUSEID/DISTNAME-VERSION.SUFFIX. That's it.
Maybe to PAUSE and the CPAN shell, but not to everyone else. search.cpan uses
the distribution version. Operating system vendors rolling packages use the
distribution version. They have to be able to compare it.
And its a little crazy that the CPAN shell goes by individual module versions
and not by distribution version. What other software works that way? Its an
artifact of our lack of an install registry.
> My recommendation/assertion: The "version" key MUST match the VERSION
> portion of the filename. (And the "name" key MUST match the DISTNAME
> portion of the filename.)
If that's the case, then numify the archive name to avoid extending version
parsing complexity.
> META.yml versions absolutely should not required to be normalized.
> The cats are out of the bag, the barn doors are already open or pick
> your metaphor, but crazy version numbers are already on CPAN and may
> get bumped up in the future, so we want META.yml to accommodate them.
>
> If someone specifies a crazy distribution version number to M::B and
> wants the tarball created that way, then META.yml should reflect that.
That's fine. Those are exceptions and they get everything they deserve.
> However, I can see an argument that Module::Build (and other toolchain
> tools) should numify version objects when *generating* a distribution
> version based on a module version. So that even if the
> "dist_version_from" module uses qv("v1.2.3.4"), the distribution
> version becomes 1.002003004.
This effectively castrates version.pm, which is fine by me, but we should be
clear what its doing.
--
"Clutter and overload are not an attribute of information,
they are failures of design"
-- Edward Tufte
