::VERSION - what is it, why do we need it, is there now something we should differently.
Updating to new releases of a dist is probably the most important purpose of version. However the old perl motto is there is more than one way to do it.
Presently nice programmers are to place a VERSION in each module. There is no mandate to do so, nor is there a mandate that the version change for each distribution.
This generates all kinds of problems. Some dists, the version numbers all reflect the dist version. Some versions are simply an rcs or similar version number of the specific file. Many modules have no version.
Brad Fitzpatrick recognized what a pain in the `donkey` it is to update all the version numbers and has an auto-update in his Shipit dist. Nice.
Can we do better? Should we do better? Is there something better? Is it not a problem?
Can it also play into improved security in today's hacker-infested environment?
What if _ONLY_ the dist and it's related top-level module contained a <pkg>::VERSION number. Suppose all other modules part of the dist referred to the top-level module for a version number?
Is not the top-level version what most people want/need to know to be able to update to the latest 'version'?
Git is nice, it seems to be a rage, and has a nice concept and utilization of hashes.
What if we introduced a <pkg>::HASH::SHA1 in each package? Or something similar.
What if this became a part of perl core? Does calculating the hash cost much? It could certainly be calculated at perl's parse time. With 'require' you first have to traverse the filesystem to find the file, then open it, then read - all very costly - now you have something to parse, so why not do a hash calc on the side while parsing.
A hack is to place code in each module to calc its own hash when a version sub is called.
A better hack it to place it in an appropriate base class within the Moose/Class::MOP subsystem. Better yet would be in perl core.
This could be use to verify the file on disk is same as what the admin installed (in case of break-in) via some other data-repository of known hashes.
It also provides a unique version on the file - same hash - same file-version. For the dist version, it would auto-query the top-level module.
No more touching each file for each dist just to update the version - ugly. Diff lists show real changes for a given dist. Not a complete listing of files just because the version number got bumped.
Not the same as git, but conceptually analogous.
Just something to think about...
Best regards,
..Otto
Great example of VERSION/CPAN pain...
DBM-Deep-1.0014 v. DBM-Deep-1.0013
The ...13 version has DBM::Deep::File version 1.0013, but the ...14 version has dropped the version, so using cpan, it will load 1.0014, great, but then the next time, it thinks that the unversioned files of 14 are less than that of the versioned files of 13, so it wants to install 13, but you have 14 installed.
One word for this: INSANE
More pondering... So how do the various install pkgs (e.g. Module::Install) determine if your installed version of a module (which is what is specified in the prereq list) is at?
Fundamentally it is either effectively *grep'ing the module code file or evaluating and then querying the <pkg>::VERSION value. (Just looked.) Many rely upon ExtUtils::MakeMaker, which has a MM, which contains the parse_version which effectively is *grep'ing the code!
So CPAN.pm (to fetch new versions) uses MM as do the installers once they are downloaded and need to determine if all prereqs have been met.... Furthermore I believe that the PAUSE/CPAN indexing / searching mechanism is likewise *grep'ing.
Who actually evaluates the <pkg>::VERSION value???
This all does not seem to be hygienically clean or nice.
So why play the games of problematically *grep'ing when we can absolutely calculate a hash? This provides exactness of identity, not wishful thinking the author updates their concept of version. This hash can be mapped to a dist.
Some may argue that it then requires some kind of data repository, and that is problematic.
Right, don't we already depend upon a data repository to use CPAN? - The 02packages.details.txt.gz and 03modlist.data.gz are a requirement are they not? Why not add to or change the functionality...
In reply to <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support - what NOW makes sense. by otto
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |