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

LaFayette

TL;DR:
(1) recommend switching game versioning to something like: 2026.06.0.54325, that is <calver>.<recommended release number>.<build number>. This is "calver'ish", inspired by calver.
(2) set cadence for recommended release to be quarterly and automated
(3) new downloads will always be the latest
(4) existing players will be prompted to update when a new recommended release is published

To read more about 'calver', please see: https://calver.org/

Rules / definitions:

calver = YYYY.MM and this matches the year / month of when that release was created. We create a release after every code update.
recommended release number this is an increasing sequence and each new number will trigger a notification to existing players that they should upgrade. We will automatically create and bump the recommended release number once each quarter on the first of the month, specifically: Jan 1, Apr 1, Jul 1, Oct 1
build number this is the count of total number of code changes. We currently have this in our version numbering and we'll keep it. The revision number uniquely identifies a release.

It has been previously discussed that with the 2.7 release we will change our release strategy to be "continuous release". Every update to the game engine would be a release (rather than a pre-release). This would impact players downloading from the website, which is configured to download the latest 'release'. I suggest we keep this strategy in order to avoid manual releases and allow for bug fixes to be immediately available.

Second, the concept of "recommended release" must be fully automated and scheduled so we can avoid the cycle of delayed releases by removing the dependency on maintainer availability.

The net effect, every update will be immediately available, players are automatically asked to upgrade once every 3 months. This dovetails with an update to versioning strategy so that the release schedule and versioning will work hand-in-glove.

Let's walk through some examples, starting with a version at: 2026.06.0.100 (the build number is simplified to be 100, we are currently in the 5 digits for the build number)

2026.06.0.100 < starting version
2026.06.0.101 < code update
2026.06.0.102 < code update
2026.07.0.103 < code update and the month rolled over
2026.08.0.104 < another code update and month rolled over
2026.10.1.104 < Oct 1st is a 'cut date' we automatically create a new recommended release
2026.10.2.105 < let's say we identify a bad bug and patch it, we can update the recommended release version on an ad-hoc basis to toggle in-game update prompts
2026.10.2.106 < code update
2026.12.2.107 < let's say on Dec 31, we are at this version
2027.01.3.107 < Jan 1st is a cut date, the recommended release is automatically created with a new recommended-release number

Panther

@LaFayette That appears to be a good and understandable system.

ubernaut

@LaFayette love it

LaFayette

One big variable, is the cadence, how often for recommended releases.
Once a year? Twice? Three times, four times?

There's a concern that if activity drops to be lower, then we might have recommended releases that contain very little. I wonder a bit if 3 times might be the sweet spot. Any thoughts?

beelee

@LaFayette

Nice work

I would think fewer as opposed to more, as the majority of Players don't upgrade that often

TheDog

@LaFayette
Lets try 3 times a year, hopefully it can be easily changed if required.

beelee

Perhaps for the first time, you can check in a couple weeks ahead of whatever release cycle is decided on and if it has low activity, move it to the next cycle ?

Idk if that is practical.

Panther

@LaFayette said:

One big variable, is the cadence, how often for recommended releases.
Once a year? Twice? Three times, four times?

There's a concern that if activity drops to be lower, then we might have recommended releases that contain very little. I wonder a bit if 3 times might be the sweet spot. Any thoughts?

I'd suggest two times, as there are times where coding activity goes down to almost zero, as well as times where it is quite high (currently). So two times seems to be a realistic frame.

LaFayette

@Panther Ubuntu releases twice a year, so there is precedent there.

I feel like TripleA gets an uptick in activity before Thanksgiving. Having players upgrade before then feels to make sense.

So, if we do twice a year, that would be be a Nov 1st recommended release and then a May 1st recommended release. That is probably a good place as any to start. We'll target to get this next release out ASAP and then the next scheduled recommended release to be Nov 1st.

Cernel

@LaFayette said:

So, if we do twice a year, that would be be a Nov 1st recommended release and then a May 1st recommended release. That is probably a good place as any to start.

As a non-developer, I would go with whenever tends to be the period when developers have more free time (asking the other main developers).

(I think more people being online during releases can be argued either way about being a good or bad thing.)

I would actually go with quarterly "releases", so, when one gets skipped, it becomes a 6 months wait rather than an 1 year wait (and 9 months instead of 1.5 years if two get skipped).

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);
    }