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

In this case "backup" is a Git repository and the Git history is the authoritative file history, so tracking versions at file granularity in the files seems superfluous to me.

Does perl-reversion -bump also increment $VERSION in files that were not changed at all? That would be a problem for me, since it would create many "same file, only different" versions of most of the files in WARC — I tend to only change a few files to implement the next step on the roadmap, then make another release to get at least CPAN Testers feedback.

Copying files between distributions is more of a concern to me. On one hand, that is perfectly allowed under the licensing, but on the other, it violates encapsulation and sets (other people) up for future maintenance problems. Is this really that common in the CPAN community? If so, I may need to abandon the idea of applying SPOT to distribution versioning and put unique $VERSION literals in each module.

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

Replies are listed 'Best First'.
Re^3: Using a Single Point of Truth for $VERSION in a distribution? by Corion (Patriarch) on Apr 18, 2020 at 05:51 UTC
This may or may not be common in the CPAN community, but if a file is installed on some disk, it may get copied somewhere else instead of reinstalling the set of files from CPAN. Or it may get restored from backup, as I already said. The `$VERSION` is not for you, the module author, but for the sysadmin and/or programmer to find what version of a file they really have, and which distribution it belongs to. Only in the second step, it is also for you, because bug reports will be much easier to resolve when you have a unique version. And yes, you will have to get accustomed to a "bump version numbers, regenerate META files" commit in your commit history for every release.	[reply] [d/l]
Re^4: Using a Single Point of Truth for $VERSION in a distribution? by jcb (Parson) on Apr 19, 2020 at 02:58 UTC
I already have an "update metadata for release" commit, where (at least) the `Changes` file is updated with the actual date of release and any change notes that were not made in earlier commits. A few extra "bookkeeping" commits are not a problem, especially if I am already making them. I bump version numbers for continuing development after the release, producing another commit, with the actual release tarball stored in a tagged commit that branches in the middle. Currently, I have three places to update: `README`, `Changes` (starting a new block), and `lib/WARC.pm` itself. This is sufficiently simple that I currently do it manually. I had overlooked the case of a sysadmin restoring from backup and only loading part of Perl's module library for whatever (presumably good) reason. So the typeglob aliasing is actually a future maintenance problem waiting to happen if someone loads a partial fileset or, more likely, mixes two filesets such that the only way I would be able to know what happened would be to ask for the SHA1 hashes of the offending files and check them against the Git repository, which would reveal that two different releases had been combined. The only solution seems to be to somehow tag each file in the release with the release version it was packaged in, either as an actual `$VERSION` literal or in a comment. ("`WARC::Record 0.0.1 from WARC release 0.0.1_1`") I will need to script the release process to make this work but that is probably a good idea anyway. Is there a convention for a subtree in a CPAN distribution that contains "author tools" used for maintaining the code but not involved in testing or installation?	[reply] [d/l]