in reply to <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support - what NOW makes sense.

Suppose modules used git SHA1 numbers as versions. Now I want to install Module X. Module X needs module Y, and at least version 81AC89FE38.... I have version DA21348FF0... installed. Quick, do I need to update module Y to be able to use module X or not?

What if this became a part of perl core?
Replacing a working system that is independent of Perl core support (and hence will work with quite old versions of Perl) with a system that needs perl core support (and hence cannot become active for another 5 years or so, until 5.12 comes around) seems like 77 giant leaps backwards.

For all the suggestions I've heard the past years to change the CPAN VERSION handling, yours is the most insane. By a long shot.

  • Comment on Re: <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support - what NOW makes sense.

Replies are listed 'Best First'.
Re^2: <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support - what NOW makes sense.
by otto (Beadle) on Apr 21, 2009 at 22:37 UTC

    Suppose modules used git SHA1 numbers as versions. Now I want to install Module X. Module X needs module Y, and at least version 81AC89FE38.... I have version DA21348FF0... installed. Quick, do I need to update module Y to be able to use module X or not?

    Exactly the point. The concept of a version number and a file identification should be separate concepts.

    As analogy git has separated the concept of a file name and the file contents. The file contents is a blob which has an id. The id is then related to a name in the tree object. They are two separate concepts. The concept of version number, more like a git tag, identifies a group of items, a hash uniquely identifies the contents of something, in the case we are discussing, files as related to modules and packages in perl.

    ...yours is the most insane. By a long shot.

    Thank you - either i'm insane or cutting new trails :)