Version Management for release 0.5 and Beyond

[DeathFishAtEase]

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.

[github-actions]

Nightly build for this pull request:

• compiled-dll-1d3cf7ccae26cfb8353fdedb3daa3fe27c518a48.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]

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]

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]

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]

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]

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]

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]

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]

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]

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 版本更好的选择。