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

[LaFayette]

Also worth mentioning, with the change for every code update to be "released", developers will need to get in the habit of putting anything that is slightly risky behind a feature flag so that the update can be tested & gated from general availability. That's at least one strategy that can be employed to help maintain stability in an otherwise very brittle codebase.

[VictoryFirst]

@LaFayette Thanks, my understanding has been improved. However, I still stand by my point that we should probably not have less than four releases every year. My point was that existing users who want to upgrade are not notified on a frequent basis. If they want to upgrade sooner, they'd have to go to the TripleA website from time to time and check if there has been an update. This can not be prevented, but it can be mitigated by making the number of recommended releases every year more frequent. Four already sounds like too little to me, however I understand there are other considerations regarding code activity and download counts.

Apart from that, i think this new release strategy is actually pretty good. We just have to agree on the number of releases every year.

Developers will need to get in the habit of putting anything that is slightly risky behind a feature flag so that the update can be tested & gated from general availability.

Could you tell more about how this will work in practice? Like releasing them as a beta-testing feature or as pre-release?

[LaFayette]

If they want to upgrade sooner, they'd have to go to the TripleA website from time to time and check if there has been an update.

• Which scenarios do you imagine where a user would want to upgrade sooner?
• Downloading from the website always gives the very latest, there might not be a lot to check per se
• We can always manually toggle a new 'recommended release' to skip ahead of the scheduled 'recommended release'

however I understand there are other considerations regarding code activity and download counts.

Funny enough, by having the latest always be downloaded, we're really torpedoing the download count. It'll be resetting on a pretty frequent basis as far as Windows is concerned.

Could you tell more about how this will work in practice? Like releasing them as a beta-testing feature or as pre-release?

Here is an example that has been in the code for some time. The 'relay server' migration/technology upgrade has been a work-in-progress for some time. An example below from EvaderRetreat.java, also look at ClientSetting and the beta flag there. There's individual flags for specific features, and an overall 'beta-feature' flag:

    if (ClientSetting.useWebsocketNetwork.getValue().orElse(false)) {
      parameters.bridge.sendMessage(
          IDisplay.NotifyRetreatMessage.builder()
              .shortMessage(shortMessage)
              .message(longMessage)
              .step(step)
              .retreatingPlayerName(retreatingPlayer.getName())
              .build());
    } else {
      parameters
          .bridge
          .getDisplayChannelBroadcaster()
          .notifyRetreat(shortMessage, longMessage, step, retreatingPlayer);
    }

[Cernel]

@LaFayette I meant that the push-to-update is likely going to cause a spike in the amount of problem reports (as well as complaints) from the community on that day and shortly thereafter, especially regarding the risk (however low a possibility) of suggesting an update much worsening the user's experience.

[Cernel]

And I guess the maintainer/maintainers will retain the capability of skipping a scheduled recommended release if they feel like it's better not to (in case the current release having some serious regressions). Or not? This was the only potentially proactive thing I was assuming on this matter (of course the recommended release happening if no maintainer takes any actions).

How about the recommended release being automatically skipped if there is one or more open GitHub issues with the "Regression" label on it?

(I obviously also assume the recommended release will not happen if it is the same as the previous one, like in case it is seasonal and no new version of TripleA was release in 3 or more months. Right?)

[LaFayette]

And I guess the maintainer/maintainers will retain the capability of skipping a scheduled recommended release if they feel like it's better not to (in case the current release having some serious regressions).

If the upcoming recommended release has a serious regression, then so would the version that the new players are downloading. The way to deal with regressions will be to immediately start rolling back code updates until the regression is removed. It's easy to restore those code updates, but the reaction will be to start rolling back as soon as any issue is discovered and then roll forward with a confirmed fix. Thereby, regressions should be resolved essentially immediately, not with fixes, but with rolling back. That buys time for doing a fix properly, avoids trying to patch broken code with potentially more broken code, and reduces how many other updates that go into the code base that could be broken themselves (it's a lot easier when something breaks if it's obviously the last thing that was merged, it's a lot more difficult when we are testing for the first time months after the fact and there are multiple things interacting with each to cause a breakage)

How about the recommended release being automatically skipped if there is one or more open GitHub issues with the "Regression" label on it?

That idea was floated, the regression label might become obsolete. It will depend how significant an issue is, but generally the response will be to remove all recent code updates until the culprit is removed.

(I obviously also assume the recommended release will not happen if it is the same as the previous one, like in case it is seasonal and no new version of TripleA was release in 3 or more months. Right?)

This is in part a rationale for 6 month cadence. Helps avoid that situation and reduces the frequency for players being asked to update

[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