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

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.

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 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]

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 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]