Automated Versioning and Releases

Intro

Source Codebase Data Codebase Composite changes game version

The main motivations for these changes are:

• Merging the Source and Data repositories so that changes that affect both of them are unified in single Pull Requests.

  Currently, if Source changes are made that require follow-up Data changes then a PR must be opened, reviewed and merged separately in each repo (and vice versa)

  The current approach to this is careful manual synchronisation of two pull requests across two repositories, but this promotes certain issues.

  The lack of coupling is undesirable as it:

  • reduces the human visibility of a set of changes that affect both codebases, as they require two pull requests with two separate reviews
  • adds overhead to the contribution, for the same reasons as above
  • can lead to a desynchronised repository state, where Source changes have been approved and merged but the Data changes have not, leaving the game effectively "broken" on the development branch
  • severely limits the viability of the unified versioning scheme discussed in this document, as outlined below

  If merged, the two codebases will still reside in directories independent of each other. As such, this unification will not increase the number of merge conflicts that a contributor experiences, even with high commit frequency to both codebases.

  Specifically, Data/Source changes will only conflict with commits against their respective codebase, so the inclusion of the Data codebase will not affect Source commit history.
  If composite work experiences merge conflicts, those conflicts would occur in any case with the current setup.

• Achieving the unified codebase required to version the game as a whole

  When trying to version the packaged game, we run into an issue caused by two of its current features:

  • As discussed above, there is no strict synchronisation between the Source and Data codebases.

  • The property used to compare mod compatibility (the GameVersion) is set before build-time, and "baked" into the executable code when it is compiled.

  These two features cause issues when trying to provide a definitive game version for mods to depend on.
  The Source codebase, which is responsible for the GameVersion, needs to be aware of any changes in the Data codebase, and those changes must retrigger a full build of the game and increment the version correctly.

  The issue is compounded when dealing with composite changes, which must somehow be recognised as a single batch to avoid double-incrementing the game version.

Updated Versioning Scheme

See here for details Switch from Pre-X to proper semver

Can either start from 1.0, or force push a tag to start at 5, it's fairly arbitrary.

Dev builds vs main releases

This will take a small announcement so people don't get confused.

mods will no longer need to be updated for minor releases

Automated Versioning

Conventional Commits

Extension of above, by tracking commits we can auto-increment the version number.

The actual committed value of the game version is no longer the source of truth, it now comes from tags and branches. At no point should we be required to manually increment the version. It'll be overwritten on push anyway.

Distinction between data and source code changes

Automated Releases

Semantic Release

Follow-on from monorepo and auto versioning:

Requirements

Monorepo, as otherwise versioning the source / data is too hard.

Devs must have at least one Conventional Commits spec commit in a push to correctly increment the version number and trigger a build

No more manual changes to version number

Dev builds will still suffer from needing to update the mod SupportedGameVersion each release, as they must match exactly.