RFC versioning template changes

[tiborsimko]

When a change to an Invenio module is accepted in the cookiecutter template, the
change must be usually propagated to all the various Invenio modules for
consistency.

The old technique was, roughly, to create issues in respective repositories, so
that modules maintainers are aware of the needed change. The module maintainers
(or the Invenio "core" team) can then work on propagating the given change to
their respective modules according to their respective time schedules and the
nature of the change (e.g. its "scriptability").

Some time ago, we discussed with @kaplun that it might be useful to keep a
"template "version number" -- perhaps incremental, perhaps SHA1 -- so that
module maintainers can see more easily where they are and what has to be done.

A hypothetical example:

• cookiecutter template version 123
• invenio-records is on 122
• invenio-github is on 114
• invenio-oauthclient is on 78
• ...

This is similar to how DB schema may be numbered in an application to keep
track of changes, e.g. think Alembic without the "automatic upgrade" part that
the module maintainers must do mostly "manually" here.

WDYT?

[lnielsen]

I think this goes hand in hand with the bigger question of automating as much of the tedious repository maintenance as possible so that maintainers can focus their efforts on where they are really needed. Perhaps we should start collecting examples of what tasks we can automate, this one being the first? Where would an appropriate place be to collect such examples?

[krzysztof]

Where would this version be stored in an Invenio module?

SHA1 of head commit would not require bumping up any numbers on cookiecutter template updates.

[jirikuncar]

It would be also nice to keep the "replay" information in the repository (https://cookiecutter.readthedocs.io/en/latest/advanced/replay.html) together with the template version number.