Release Strategy & Versioning Proposed Changes - CalVer and Quarterly Recommended Releases

[RogerCooper]

@LaFayette What happens if there is bad update, that breaks part of the game. How can we go back to good prerelease version?

[ubernaut]

@RogerCooper same question came up on reddit just now but i believe @lafayette covers that in the highlighted example



@lafayette wanted to share this comment with you as well:

[LaFayette]

@rogercooper @ubernaut , generally the strategy will be to revert the change that introduced the bug. We should avoid trying to fix newly introduced problem, but instead roll back. Rolling back is generally safer because you are more likely to be returning to a stable state rather than risking adding more broken changes on top of broken changes.

Git makes it really easy to revert the revert. That is the thing that should then get patched. So, the first goal is to remove the bug, get back to stable state, DO NOT FIX, but revert. Once done, re-introducing the change with a patch has no urgency, it can be done carefully and correctly the second time.

Further, because all code updates are live, and it's super easy to create things that are broken, the developers should try to "gate" features behind "flags" that are in the "testing" settings. That way we will be "opting in" to test out those features, and once well tested, we can remove the "gate" and make the feature be live. The developers will need to try and get in the habit to do this frequently in order to reduce risk.

cc: @frigoref & @victoryfirst (FYI)

[ubernaut]

@LaFayette love it posted that as an additional reply on the reddit post

[LaFayette]

@RogerCooper I missed your earlier question and didn't quite address it in my last response to ubernaut.

Updates can be rolled back from the Github (GH) web-UI by clicking buttons.

First, find the PR with the update that should be rolled back and find the 'revert' button. Click that, GH will create a PR with a revert for the update. That can then be merged like any ordinary update. All of that can be done with button clicks, for example:

Note the revert button in bottom right:

Then, in the new PR that is created by GH, clicking 'auto-merge' will merge the update once the build checks have passed:

[LaFayette]

I suppose it is worth pointing out that a 'revert' in git is just an undo update. The code history in Git is write-once. Git never deletes anything. So, in a revert update, based on the reverted change: any lines that were added are removed, and any removed lines are re-added. So, a revert is a new update, it just an inverted update to cancel out a previous one.

Revert PRs are not at all special to Git, it's just another update. Once a revert is merged, a person can revert the revert update, add more changes to it, and then merge all of that as one bundle.

So, a flow might be like this (the letters on the left hand side represent the commit ID, AKA the commit SHA):

a43ae  Some update that introduced a bug
3ads2  Revert: Some update that introduced a bug
fae54  Revert: Revert: Some update that introduced a bug + Bug Fix

---

Changes to the code base are "squashed" together. When a person clicks the revert for the revert, that creates a new proposed change. Bug fixes can be added to that proposed change, then it'll all be squashed together as a single commit that is then released.

For example, when reverting the revert, this change would be proposed:

abc12  Revert: Revert: Some update that introduced a bug

In that proposed change, we can add the bug fix, eg:

abc12 Revert: Revert: Some update that introduced a bug
fea23 Bug fix

Then, when merged, that would land on the main branch and in the history as one commit, eg:

fae54  Revert: Revert: Some update that introduced a bug + Bug Fix