Re^3: Using a Single Point of Truth for $VERSION in a distribution?

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".

Comment on Re^3: Using a Single Point of Truth for $VERSION in a distribution? Download Code

Replies are listed 'Best First'.
Re^4: Using a Single Point of Truth for $VERSION in a distribution? by jcb (Parson) on Apr 19, 2020 at 03:25 UTC
Now that you mention it, I have encountered that problem when trying to trace `Changes` across modules that have been split from or combined into parent distributions. You are close: I am trying to preserve the invariant that each file is only changed in the repository when it is meaningfully changed. A file that has not been meaningfully changed since release 0.0.1, should indicate as such in Git, at least on the `master` branch... and that gives me an idea that preserves the ability to run `prove` on the working tree even though the tests verify that `$VERSION` is checked... I could have the release scripts replace the typeglob aliases with `$VERSION` literals, build and test the new release, store the release tarball, then use `git reset` to revert back to the development line in the post-release script.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Using a Single Point of Truth for $VERSION in a distribution?
by jcb (Parson) on Apr 19, 2020 at 03:25 UTC

Now that you mention it, I have encountered that problem when trying to trace Changes across modules that have been split from or combined into parent distributions.

You are close: I am trying to preserve the invariant that each file is only changed in the repository when it is meaningfully changed. A file that has not been meaningfully changed since release 0.0.1, should indicate as such in Git, at least on the master branch... and that gives me an idea that preserves the ability to run prove on the working tree even though the tests verify that $VERSION is checked... I could have the release scripts replace the typeglob aliases with $VERSION literals, build and test the new release, store the release tarball, then use git reset to revert back to the development line in the post-release script.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom