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