Thanks for the feedback
My ref's to git was simply as a jumping ground, not specific applications.
...git keeps a database that lets you map that SHA1 hash to a date, author, log message and diff
Again analogy. Remember that 02packages.details.txt.gz as dist'd by cpan contains the following: module, version, dist. So each module has a version or undef. So there really is a "current" concept of mapping a hash->module->dist as "current". Furthermore a concept of top-level module can provide a concept of version, which applies to the whole dist.
It also implies that you can't require a minimum version of a module, just one specific version.
Not true. Again the top-level module is the "version" for the whole dist, and hence all modules part of the dist. So you could spec a min or max version for a "module" which would imply the top-level module of the dist, and you get the min version required result.
...but I don't think it's feasible to plug onto the existing system
Actually I'm working on a module in which I hope to incorporate some of these ideas
...discussions don't deploy code. Programs do.
It is the automation of this that I'm suggesting. Shipit is facilitating a better solution, but that solution pushes a version in each file. I question whether this is needed by posing the question of what ::VERSION is really used for.
In reply to Re^2: <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support - what NOW makes sense.
by otto
in thread <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support - what NOW makes sense.
by otto
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |