Add version number (or something equivalent) to hashes?

[Jean1995]

In case an update of PROPOSAL changes something about a cross section parametrization, the hashes don't change, but the contents of the interpolation tables might change.

This means that if using a newer PROPOSAL version where PROPOSAL finds tables created for an old version, this can cause outdated or even completely incorrect results.

The simplest solution would be to add the version number to the hash. However, this would also mean that every version update (even without any changes to the physics), a new hash will be required. Alternatively, one could have some kind of "internal version number", either for PROPOSAL in general or even for individual processes (?), which changes only if there are physics changes. I am open for better suggestions.

[asandrock]

Having a version number which is incremented by hand to account for physics updates would be a solution, but if this has to be done by hand, this is certainly going to be forgotten at some point in the future. This would be better than having no solution at all, but it certainly does not seem ideal.

[maxnoe]

Boost serialization has a mechanism for versioning classes:
https://www.boost.org/doc/libs/1_83_0/libs/serialization/doc/tutorial.html#versioning

You can at least use this to raise proper errors / re-generate the tables when trying to load unsupported versions.

But probably you also should include the version somehow in the generated filename, so that you using multiple versions of proposal in parallel on the same machine (e.g. when you do development and switch branches) doesn't lead to constantly re-computing the tables.