http://qs321.pair.com?node_id=11115725


in reply to Re^2: Using a Single Point of Truth for $VERSION in a distribution?
in thread Using a Single Point of Truth for $VERSION in a distribution?

If I put separate $VERSION literals in each module, I want them updated if and only if that module has been changed since its version was last updated.
From a module user's viewpoint, that is an astoundingly bad idea, assuming that all the modules are packaged in a single distribution. This has nothing to do with a fetish for "density", but think about the confusion it's likely to cause users if they install MyModule 1.23 and it comes bundled with MyModule::Foo 1.21 and MyModule::Bar 1.00. "Ah, crap! I've got an old version of MyModule::Bar - I should update that and get the current version, but when I go to install 1.23, nothing happens! WTF?!? Is this thing broken? Has Bar been deprecated or discontinued? Where are they hiding the current version, if it even exists?"

I get the impression that your real goal here is that you're trying to minimize the number of "meaningless" changes committed to your git repository. Dist::Zilla can provide this for you, while also having the same version number in each file. Not because it aliases the main module's version number into all the other files, but because it allows you to put "tags" into the file representing metadata (such as a version number) and then replaces the tags with the actual metadata values when it builds the release package. The "real" version of the file, the one in git, contains the tags, so it never needs to change for metadata updates, while the distributed versions contain the literal metadata values in each file.

And, yeah, I realize that you may be a bit iffy about the distributed files not being identical to the files in git (I know I was, when I first heard about Dist::Zilla), but it's not really any different than a C program where you keep the source files in git, but distribute compiled binaries. The "compiling" that dzil does when building the release is much simpler and less extensive than what a C compiler does, but it still fits the same general pattern of "keep your manually-created source files in git, but not the files generated automatically from them".