Initial thoughts (without careful consideration....)
Post by Nick MorrottWith a future move away from CVS
I presume git. Before getting into the minutia,
have you considered also changing the various
workflows in the process? While moving to
something quite so formal as the Linux model
of individual contributors providing pull requests
to the "coordinator"/"release manager" might be
overkill, there are other approaches using
sub-trees and submodules (which have different
pluses and minus). And moving to release tags
(perhaps of the form vYYYY.MM?) and using
git-describe to obtain the tag might be a net
positive for releases. A change of SCM offers
an opportunity to consider what the approaches
should be (of course at a higher conversion
overhead for the contributors).
Post by Nick Morrott, grabbers will lose the ability to
use the CVS "$Id$" file version tag, which is heavily used at the
moment to provide data for $grabber --version.
Given that the currently provided perl module depends
on parsing the $id$ field, maintaining it in some way is
likely necessary for it to be meaningful at least in the
short term.
I do not mind requiring people to manually maintain the
value, but I do expect that will mean for some grabbers
that that means the number will never change (easy
to forget that step when it has been automagically
done for you for years).
There is some limited support for the $Id$ field flag
by specifing a "ident" attribute in the .git/info/attributes
file for cvs compatibility, but (as I recall) it really does
not do what you might like here.
I guess my personal preference would be that
in the long run to modify the Options module to
support a different parsing for versioning, and
then eliminate the legacy $Id$ entirely. Git
really does not care about versioning updates
as cvs does.
And while I think I would recommend against
it, here is someone who got so unhappy about
not having $Id$ support he rolled his own:
http://www.immediatec.net/2016/09/07/git-correct-id-keyword-expansion/