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

[Cernel]

On the other hand, to minimize the risk of burn-out in doing such a thing (which I guess is easily done but very unengaging especially in case of problems emerging right after the community at large gets to "test"), the best choice would be doing it only once per year and exactly in the time of the year (whatever it is) where developers tend to have more free time and more willingness of using their free time to manage TripleA. Add to that that, if one thing happens once a year, it is much easier for a person immediately to remember "it's TripleA release time", so it can become more easily part of the tribal knowledge of the community (meaning that people will be more likely to accept problems as part of an expected process rather than feeling like the developers are randomly thowing lemons at them) if the process becomes consolidated.

[RogerCooper]

Would pre-release versions be available with any change? I am always using the pre-release.

[VictoryFirst]

@LaFayette Why is there chosen for this release strategy? What are the pros and cons? In other programs, there is a release strategy I like that notifies you every now and then of an update (like every 1-2 weeks). Then, as the user, you have the option to install the update, ignore it for now, or ignore it completely and not be reminded of it anymore.

I think there are definitely people who would like to have the latest features and fixes, and if they get only notified like once every three or six months, they would have to go to the website themselves to see if there is a later version, somehow find out what has changed, and decide if it's worth updating.

It would be better I think to have definitely not less than 4 releases a year. Probably more like 6 or 12 (simply every month). If we would do monthly releases, in an ideal world, players would get a pop-up the next time they start TripleA after a release, stating that there is a new recommended release, along with an overview of what has changed. Then, players have the option to install it (also ideally, let the program automatically uninstall the current version and install the new one instead of having to do that yourself), or to ignore the update for now and be reminded on the next start-up, or to ignore it completely and only be reminded once the next recommended release is out.

There might be an argument against monthly releases that the program might not see enough updates in that time period. As I have started contributing only recently, I might have jumped in at a time that happened to have a lot of activity, but other than that I cannot imagine that in an entire month, nothing of importance has been done to the program. There is always some kind of improvement that would be nice to have for the user, regardless of how small it is. And once in a month is long enough that it wouldn't start feeling intrusive to a user, something that could happen with weekly releases. You don't want to bombard them with updates as that can become annoying over time. Twice a year sounds like way too little. A lot can happen during that time and might introduce too many changes and updates at once.

Another argument would be that there wouldn't be enough new downloads that would prevent the TripleA installer from being flagged by Windows Defender when running. I can concur with that, but I think the majority of the downloads would come from users updating, not so much from new users downloading the program. So increasing the time period might not help as much as it might seem. But we would have to do some experimentation on that.

Given everything, I would suggest simply starting with quarterly releases, that sounds like a good start, and then observe what the general feedback is from the users, and also keep an eye on the number of downloads.

[LaFayette]

@cernel / @victoryfirst , I think you might have a slightly shaky understanding of what is being proposed.

First, EVERY code update will be a "release". That means every new code update will be the thing downloaded from the website. Every new player will download the very latest version of the code from the website, every time, all the time, automatically.

Then, for existing players, there is a concept of "recommended release". This is an existing concept but has never been named as such. Previously the "release" was also the "recommended release" and the two were not explicitly separated.

The recommended release toggles an upgrade notification to players. The recommended releases will be fully automatic and based on a schedule. They will happen with zero involvement from the project maintainers. There are even fewer project maintainers than there are contributors, thus an active contributor will have their updates be reflected in the live download much sooner, and secondly there will no longer be a dependency on a maintainer to coordinate a recommended release process at some time later.

[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