Release Strategy & Versioning Proposed Changes - CalVer and Quarterly Recommended Releases
-
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 publishedTo read more about 'calver', please see: https://calver.org/
Rules / definitions:
calver=YYYY.MMand this matches the year / month of when that release was created. We create a release after every code update.recommended release numberthis 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 1build numberthis 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 be100, we are currently in the 5 digits for the build number)2026.06.0.100< starting version2026.06.0.101< code update2026.06.0.102< code update2026.07.0.103< code update and the month rolled over2026.08.0.104< another code update and month rolled over2026.10.1.104< Oct 1st is a 'cut date' we automatically create a new recommended release2026.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 prompts2026.10.2.106< code update2026.12.2.107< let's say on Dec 31, we are at this version2027.01.3.107< Jan 1st is a cut date, the recommended release is automatically created with a new recommended-release number
-
@LaFayette That appears to be a good and understandable system.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login