Version Management for release 0.5 and Beyond by DeathFishAtEase · Pull Request #2098 · Phobos-developers/Phobos

DeathFishAtEase · 2026-02-09T02:46:40Z

During several hours of communication, many details were confirmed. To avoid loss, Kerbiter suggested that I first update the document and create a PR draft.

The early blueprint of the new version management system was also mentioned in the phobos-chat channel of the C&C Mod Haven server:

Kerbiter 2025/7/13 17:24 (UTC)
@ Phobos Contributors I am drafting new versioning scheme to fix long ass belated releases and move to faster releases, need your opinion:

Starting past version 0.4, Phobos adopts the following types of releases:
Release - a stable and polished enough build type, except a lot more frequent and smaller.
Pre-release, previously known as devbuild, is a build type for which no separate doc version is created and which always precedes a new release version.

Each pre-release (devbuild in the past) can mark a start of a new release branch with it's new version number. Between a pre-release and a newer version on the same branch (be it another pre-release, if needed, or a release) there shall be no changes that warrant a changelog addition; in other words - there may be only fixes, minor additions and polish to new content.

The master branch as it is should be abandoned, because there's no point in merging the changes between versions, as the next version will be a new branch anyway.

@Metadorius's TODO:

ensure that we can automate generation of changelogs for any released version with the versioning change (all releases have corresponding documentation entries and versions)
actually change build metadata according to the plan
leave Debug and Release build configurations, nightly/devbuild/release should be instead controlled by compiler directives (because build configs != build type)
steal automated release builds from CnCNet spawner repo

Volunteers needed! this is long overdue, as is "devbuild" release, as is 0.5.

github-actions · 2026-02-09T02:53:26Z

Nightly build for this pull request:

compiled-dll-b03cbd88bb5e2ba688d0d2720526367579e94ea1.zip
These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

TaranDahl · 2026-02-09T07:35:59Z

I thought these shouldn't exist? Since we've already merged the fix on the pre-release, what's the use of more release versions? Should the next release after v0.5 be v0.6, I think?

Metadorius · 2026-02-09T11:04:16Z

No. We can't guarantee that ALL bugs will be fixed before release, and it is unreasonable to try so, simply because pre-release is not a wide release.

TaranDahl · 2026-02-09T11:46:47Z

No. We can't guarantee that ALL bugs will be fixed before release, and it is unreasonable to try so, simply because pre-release is not a wide release.

If we want the release to also track the bug fixes in dev, then what is the significance of pre-release?

Metadorius · 2026-02-09T12:01:52Z

If we want the release to also track the bug fixes in dev, then what is the significance of pre-release?

To provide a bug-free patched version, of course.

Dev gets new features and changes that introduce new bugs, it is almost never bug-free because of that. Pre-release doesn't get new features, only fixes, so it's naturally less bugged.

TaranDahl · 2026-02-09T14:05:58Z

Pre-release doesn't get new features, only fixes, so it's naturally less bugged.

Is there any difference between this and release? There are no new features in the release, only fixes.

Metadorius · 2026-02-09T14:12:33Z

Is there any difference between this and release? There are no new features in the release, only fixes.

Level of stability. Pre-release is "we're doing final testing to weed out bugs, polish things and prepare for the release", release is "we're confident in some level of stability".

TaranDahl · 2026-02-09T14:34:43Z

I think it's not necessary. Their functions overlap. If you want to debug on the pre-release version, then there's no need to debug on the release version.

Metadorius · 2026-02-09T15:11:01Z

I don't understand what's the problem, we've been doing pre-release all this time with RC versions, that's the same, but just more frequent (each devbuild instead of what, 5-10 devbuilds?). You can't immediately release a stable version from a develop version without it containing a good amount of bugs, hence why pre-releases. That's common tactic in software development.

DeathFishAtEase · 2026-02-10T01:27:43Z

I think it's not necessary. Their functions overlap. If you want to debug on the pre-release version, then there's no need to debug on the release version.

In my understanding, when v0.5 releases the release version, v0.6 begins pre-release, which is a preparation phase. Therefore, before v0.6 completes its release, v0.5 still needs maintenance, just as the release version of v0.4 exposed issues like the construction yard not being sellable properly and the harvester failing to create voxel debris for the flying wheels when destroyed, and then v0.4.0.1 addressed these issues. It is inappropriate to solve problems by having users switch to the pre-release version of v0.5 (in the current scenario, temporarily served by the develop branch nightly) because the pre-release of v0.5 has many new features and likely contains new Bugs. If a user believes that the new features added in v0.4 can already meet the needs of their Mod, then for the stability of the Mod release version, using v0.4.0.x patches would be a better choice than switching to the pre-release version of v0.5.

在我的理解中，v0.5 发布 release 版本时 v0.6 开始 pre-release，这是一个准备阶段，所以在 v0.6 完成 release 前 v0.5 仍然需要维护，就像 v0.4 的 release 版本爆出建造场无法正常出售和矿车被摧毁时没能创建 Voxel 碎片用于表现飞起的轮子这些问题那样，随后 v0.4.0.1 对它们进行了处理。通过让用户更换到 v0.5 的 pre-release 版本（目前情景来说暂时由 develop 分支 nightly 来充当这一角色）来解决问题是不合适的，因为 v0.5 的 pre-release 有大量新功能并且很可能带有新的 Bug。如果一名用户认为 0.4 加入的新功能已经能够满足自己 Mod 的需求，那么为了 Mod 发布版本的稳定，使用 v0.4.0.x 补丁版本会是比切换到 v0.5 的 pre-release 版本更好的选择。

ZivDero · 2026-03-10T00:59:54Z

TODO for this branch and more:

actually change build metadata according to the plan

leave Debug and Release build configurations, nightly/devbuild/release should be instead controlled by compiler directives (because build configs != build type)

steal automated release builds from CnCNet spawner repo

volunteers needed! this is long overdue, as is "devbuild" release, as is 0.5

How about CMake :hypercarville:

Metadorius · 2026-03-10T01:22:11Z

How about CMake :hypercarville:

begone demon

TaranDahl · 2026-03-10T02:07:37Z

TODO for this branch and more:

actually change build metadata according to the plan

leave Debug and Release build configurations, nightly/devbuild/release should be instead controlled by compiler directives (because build configs != build type)

steal automated release builds from CnCNet spawner repo

volunteers needed! this is long overdue, as is "devbuild" release, as is 0.5

@copilot Split this task and provide a specific implementation path.

CCCP84 · 2026-04-01T16:13:53Z

How can I help you with this PR?

CCCP84 · 2026-04-01T16:26:36Z

Adopt a Git Flow–based model: develop for new features, release/X.Y for stabilization (only fixes and polish), and hotfix branches for critical patches to already released versions.
For example, version 0.6.0-dev comes from develop, 0.6.0-rc.1 from a release branch, the final stable 0.6.0 from a tag, and 0.5.1 from a hotfix.
This allows more frequent, predictable releases while still providing patch updates for older stable versions.

(a proposal from a non-human mind)

TaranDahl · 2026-04-01T17:24:37Z

How can I help you with this PR?

Implement the works listed by Kerbiter.

TaranDahl · 2026-04-10T13:07:50Z

A bounty of 100 CNY will be awarded to all individuals who ultimately make significant contributions (to be judged by myself) to the implementation work of this PR.

Metadorius · 2026-04-10T17:49:55Z

A bounty of 100 CNY will be awarded to all individuals who ultimately make significant contributions (to be judged by myself) to the implementation work of this PR.

Since it's not easy to send money between China and the rest of the world, I'll help out by covering the expense (seems to be equivalent to $15 USD?) for PayPal or intra-Ukraine transfers, so that non-Chinese contributors have some incentive too / you won't be burdened with international transfers.

- Remove DevBuild configuration - Release configuration no longer sets IS_RELEASE_VER preprocessor directive, references across codebase changed to use RELEASE definition - Metadata is determined based on preprocessor definitions set based on compiler option BuildType (NIGHTLY, PRERELEASE & RELEASE) - Workflows updated to use the new compiler options and accomodate configuration changes

Starkku · 2026-04-10T18:50:39Z

I updated the build configuration, metadata and workflow files.

Removed DevBuild configuration
Release configuration no longer sets IS_RELEASE_VER preprocessor directive, references across codebase changed to use RELEASE definition
Metadata is determined based on preprocessor definitions set based on compiler option BuildType (NIGHTLY, PRERELEASE & RELEASE)
- Few notes regarding the metadata:
  - The version string for PRERELEASE still uses the manually incremented number in version header file f.ex v.0.4-beta1 (the 1 is the manually incremented build number). I was uncertain what the preferred approach here was so I basically left in untouched for now
  - I was uncertain what the relationship of SAVEGAME_ID should be between the different build types so it might not currently work as it ideally should, I just made sure it builds correctly with the changes
Workflows updated to use the new compiler options and accomodate configuration changes

The thing missing from the to-do list still is the automatic release / changelog generation.

Metadorius · 2026-04-11T22:34:46Z

src/Phobos.cpp

+#elif !defined(RELEASE)
 const wchar_t* Phobos::VersionDescription = L"Phobos development build #" _STR(BUILD_NUMBER) L". Please test the build before shipping.";


probably requires wording change

Metadorius · 2026-04-11T22:40:05Z

src/Phobos.cpp

 		if (_stricmp(pArg, "-b=" _STR(BUILD_NUMBER)) == 0)
 		{
 			HideWarning = true;


opinion on instead asking the user to write a full version?

Setting aside the writing of the value, does -b itself need to be changed?

Can we use a value that can be directly copied without requiring the user to manually fill it in? As long as it can be easily found on the GitHub page. Currently, the Release page contains a jump link to the commit corresponding to this version (from which the commit SHA can be obtained), as well as the SHAs of the DLL and PDB files, so something can be done: for example, having the developer who makes the Increment devbuild number commit pre-fill the value of the previous commit (since the value of the current commit cannot be obtained at this time). Of course, this example is not ideal because it is not automated enough, and there is still room for improvement in user-friendliness.

I think full precise version name should be used, and yeah I agree arg name should probably be changed

-IKnowWhatImDoing

-IKnowWhatImDoing

That sounds like a Boolean value needs to be filled in instead of a version number string :P

Metadorius · 2026-04-11T22:42:02Z

src/Phobos.version.h

+// Pre-release build number. Incremented on each pre-release build.
+#define PRERELEASE_NUM 1


do you think this would be better than, say, a string -rc1 or rc1? or pre1, beta1 etc, so semver suffix

Why bother with such naming issues?

the issue is not in the naming but in limiting ourselves if we decide that we need a different name

Why bother with such naming issues?

Kerbiter hopes to subdivide the pre-release phase into more smaller stages, so he designed things like -alpha, -beta, -rc which are equivalent to PRERELEASE_TYPE/PRERELEASE_STAGE, although I am not sure whether we have enough energy to carry out such detailed version management.

limiting ourselves

I think this is a somewhat unclear expression. Do you mean the value type of PRERELEASE_NUM or something else? Perhaps elaborating would be more helpful for understanding.

yeah. in this case it's just "maybe let's have more flexibility in case we need it in future"

limiting ourselves

I think this is a somewhat unclear expression. Do you mean the value type of PRERELEASE_NUM or something else? Perhaps elaborating would be more helpful for understanding.

I mean with the current PR approach we can only have betas. what if we think we need something more in future? or if we decide we need another pre-release instead of beta?

Metadorius · 2026-04-11T22:44:38Z

src/Phobos.version.h

+	#define SAVEGAME_ID ((VERSION_MAJOR << 24) | (VERSION_MINOR << 16) | (VERSION_REVISION << 8) | VERSION_PATCH)
+	#define FILE_DESCRIPTION "Unstable nightly build of Phobos engine extension"
 	#define FILE_VERSION_STR "Commit " STR_GIT_COMMIT
 	#define FILE_VERSION 0
 	#define PRODUCT_VERSION "Nightly Build " STR_GIT_COMMIT " @ " STR_GIT_BRANCH
-#else // Regular devbuild metadata
-	#define SAVEGAME_ID ((BUILD_NUMBER << 24) | (BUILD_NUMBER << 12) | (BUILD_NUMBER))
-	#define FILE_DESCRIPTION "Development build of Phobos engine extension"
-	#define FILE_VERSION_STR "Build #" _STR(BUILD_NUMBER)
-	#define FILE_VERSION 0,0,0,BUILD_NUMBER
-	#define PRODUCT_VERSION "Development Build #" _STR(BUILD_NUMBER)
+#elif defined(PRERELEASE)
+	#define SAVEGAME_ID ((VERSION_MAJOR << 24) | (VERSION_MINOR << 16) | (PRERELEASE_NUM << 8))
+	#define FILE_DESCRIPTION "Pre-release build of Phobos, Ares-compatible YR engine extension"
+	#define FILE_VERSION_STR _STR(VERSION_MAJOR) "." _STR(VERSION_MINOR) "-beta" _STR(PRERELEASE_NUM)
+	#define FILE_VERSION VERSION_MAJOR, VERSION_MINOR, 0, 0
+	#define PRODUCT_VERSION "v." _STR(VERSION_MAJOR) "." _STR(VERSION_MINOR) "-beta" _STR(PRERELEASE_NUM)
+#else
+	#define SAVEGAME_ID ((VERSION_MAJOR << 24) | (VERSION_MINOR << 16) | (VERSION_REVISION << 8) | VERSION_PATCH)
+	#define FILE_DESCRIPTION "Phobos, Ares-compatible YR engine extension"
+	#define FILE_VERSION_STR _STR(VERSION_MAJOR) "." _STR(VERSION_MINOR) "." _STR(VERSION_REVISION) "." _STR(VERSION_PATCH)
+	#define FILE_VERSION VERSION_MAJOR, VERSION_MINOR, VERSION_REVISION, VERSION_PATCH
+	#define PRODUCT_VERSION "v." FILE_VERSION_STR


TODO for myself: look bit more carefully into this

initial

c3d7f57

DeathFishAtEase added ⚙️T3 ❓Project policy No Documentation Needed No documentation needed whatsoever labels Feb 9, 2026

DeathFishAtEase added the No test needed This PR is simple enough, or changes no in-game logic, so no in-game testing is required. label Feb 10, 2026

Sync file changes on the develop branch

9613ff5

This comment was marked as outdated.

Sign in to view

Merge remote-tracking branch 'Phobos-developers/develop' into versioning

9699d86

TaranDahl mentioned this pull request Mar 25, 2026

Fix the issue that when an infantry passes through a cell containing a tree, it makes the cell impassable to other house #1885

Merged

TaranDahl added the Bounty available label Apr 10, 2026

Fix minor error from testing

9178a76

Metadorius reviewed Apr 11, 2026

View reviewed changes

		#elif !defined(RELEASE)
		const wchar_t* Phobos::VersionDescription = L"Phobos development build #" _STR(BUILD_NUMBER) L". Please test the build before shipping.";

		// Pre-release build number. Incremented on each pre-release build.
		#define PRERELEASE_NUM 1

Uh oh!

Conversation

DeathFishAtEase commented Feb 9, 2026 • edited by Metadorius Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TaranDahl commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Metadorius commented Feb 9, 2026

Uh oh!

TaranDahl commented Feb 9, 2026

Uh oh!

Metadorius commented Feb 9, 2026

Uh oh!

TaranDahl commented Feb 9, 2026

Uh oh!

Metadorius commented Feb 9, 2026

Uh oh!

TaranDahl commented Feb 9, 2026

Uh oh!

Metadorius commented Feb 9, 2026

Uh oh!

DeathFishAtEase commented Feb 10, 2026

Uh oh!

This comment was marked as outdated.

ZivDero commented Mar 10, 2026

Uh oh!

Metadorius commented Mar 10, 2026

Uh oh!

TaranDahl commented Mar 10, 2026

Uh oh!

CCCP84 commented Apr 1, 2026

Uh oh!

CCCP84 commented Apr 1, 2026

Uh oh!

TaranDahl commented Apr 1, 2026

Uh oh!

TaranDahl commented Apr 10, 2026

Uh oh!

Metadorius commented Apr 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Starkku commented Apr 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DeathFishAtEase Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DeathFishAtEase Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

DeathFishAtEase commented Feb 9, 2026 •

edited by Metadorius

Loading

github-actions bot commented Feb 9, 2026 •

edited

Loading

TaranDahl commented Feb 9, 2026 •

edited

Loading

Metadorius commented Apr 10, 2026 •

edited

Loading

DeathFishAtEase Apr 13, 2026 •

edited

Loading

DeathFishAtEase Apr 13, 2026 •

edited

Loading