test for ClassVersion backwards compatibility

[jpata]

In #38870 (comment) we missed keeping the old ClassVersion, which has since been readded in #38992.

It might be useful if this bug was tested for: either at compile time, statically, or via some runtime test.

[jpata]

assign core

[cmsbuild]

New categories assigned: core

@Dr15Jones,@smuzaffar,@makortel you have been requested to review this Pull request/Issue and eventually sign? Thanks

[cmsbuild]

A new Issue was created by @jpata Joosep Pata.

@Dr15Jones, @perrotta, @dpiparo, @rappoccio, @makortel, @smuzaffar, @qliphy can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[makortel]

Adding additional comment from #38986 (comment)

Version numbers 0, 1, and 2 have special meaning to ROOT and should not be used as version numbers. By convention, CMS will use 3 as the initial version number of a class which has never been stored before.

Something that could as well be caught via a test...

[makortel]

So we'd need to somehow figure out if a a change in classes_def.xml kept all previous class versions, with an ability to ignore that in case a "break" is really needed (which should be rare).

I'd imagine a check in the PR test infrastructure to be sufficient. My first thought would be to write a python script that would parse two classes_def.xml files as an input (old and new, possibly reading one of them from stdin so it could be given with git show <commit-id>:<path> without having to check the actual file out), and raise an error if

• any old class version is removed, or
• any new class version is less than 3

It would collect all possible errors from the two files before reporting. Failures would be reported in the PR test summary message in the PR. I'm not sure if failures should lead to -1 for the PR or not. Given that cases where the "failure" is expected should be rare, maybe it should lead to failing the PR tests.