Better detect incompatible versions of game VMs#998
Conversation
The previous mechanism was that one should update some constants CGAME_API_VERSION and GAME_API_VERSION, but no one ever did it. The counters only got to 3 in 10 years of development. Instead tie gamelogic ABI versioning to "major" Unvanquished releases. The assumption is that in each major release there will always be a few compatibility-breaking changes, while a point release definitely should not have any such changes or else the previous gamelogic can't run. This will help users get an informative error message when they try to replay a demo or run a mod that is not compatible with the current Daemon. Additionally there is a constant defined for whether the gamelogic ABI contains breaking changes intended for an upcoming release. This should be set on the next-release branch, for-X.Y.Z/sync. The detection of discrepancies in the compat break bit will help developers keep things straight when they are switching between the upcoming release branch and other branches, forget to rebuild stuff, set the wrong vm type flags etc. This can also be useful when bisecting the engine as you could try to avoid commits from the compat-breaking branch to avoid having to rebuild gamelogic every time. Updates to Unvanquished's update-version-number.sh will help to automatically update the ABI version and compat break bit.
|
I wonder if |
What you are suggesting is basically the current system, which I want to replace with something else
The thing I'm talking about here. Supposedly these version numbers would be bumped with each commit breaking compatibility, but they were only bumped a couple of times ever. Even if people did bump then it would be a pain since if there are 2+ compatibility-breaking PRs, they would either get merge conflicts on the version bump, or worse, there would be no conflict and thus the version wouldn't actually increase for some commits. |
|
often our engine changes don't actually break compat tho... Maybe there is a way to hash the syscalls or something and make that when we bump the ABI version? |
Well not every commit breaks compat, but probably every non-point-release engine version does. Maybe the syscall interfaces could be hashed, but those aren't everything, since also the serialization can change, or the semantics of the syscall. |
|
I suppose it's better than what we have for now, so might as well merge it until we have something better |
3 participants
Companion: Unvanquished/Unvanquished#2874
The previous mechanism was that one should update some constants CGAME_API_VERSION and GAME_API_VERSION, but no one ever did it. The counters only got to 3 in 10 years of development.
Instead tie gamelogic ABI versioning to "major" Unvanquished releases. The assumption is that in each major release there will always be a few compatibility-breaking changes, while a point release definitely should not have any such changes or else the previous gamelogic can't run.
This will help users get an informative error message when they try to replay a demo or run a mod that is not compatible with the current Daemon.
Additionally there is a constant defined for whether the gamelogic ABI contains breaking changes intended for an upcoming release. This should be set on the next-release branch, for-X.Y.Z/sync. The detection of discrepancies in the compat break bit will help developers keep things straight when they are switching between the upcoming release branch and other branches, forget to rebuild stuff, set the wrong vm type flags etc. This can also be useful when bisecting the engine as you could try to avoid commits from the compat-breaking branch to avoid having to rebuild gamelogic every time.
Updates to Unvanquished's update-version-number.sh will help to automatically update the ABI version and compat break bit.