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?