Version Management for release 0.5 and Beyond - #2098
Conversation
|
Nightly build for this pull request:
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. |
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? |
|
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? |
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. |
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". |
|
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. |
|
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. |
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
|
DeathFishAtEase
added
the
No test needed
This comment was marked as outdated.
This comment was marked as outdated.
How about CMake :hypercarville: |
begone demon |
@copilot Split this task and provide a specific implementation path. |
|
How can I help you with this PR? |
|
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. (a proposal from a non-human mind) |
Implement the works listed by Kerbiter. |
|
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
|
I updated the build configuration, metadata and workflow files.
The thing missing from the to-do list still is the automatic release / changelog generation. |
The presence of PRERELEASE_SUFFIX in version.h decides pre-release vs release instead of a separate PRERELEASE BuildType; pre-releases keep their testing warning and SpecialBuild flags. Assisted-by: DeepSeek V4 Flash
… notes generation behavior - Add release lifecycle and how-to-publish-a-release sections - Rename development builds to local builds - Tweak the release workflow so the changelog is appended to the release text you wrote, instead of replacing it Assisted-by: DeepSeek V4 Flash
Metadorius
added
Skip Changelog
Replace the Minor / No Documentation Needed labels with three per-check Skip labels (Skip Changelog, Skip Docs, Skip Credits), drop the auto-labeler and the Interop gate, and document the requirements per change type in the contributing guide and PR template. Assisted-by: DeepSeek V4 Flash
git symbolic-ref fails on a detached HEAD (CI pull request merge and tag checkouts), so fall back to the single ref pointing at HEAD via for-each-ref. PR nightlies and release builds stay stamped with their ref without needing it passed in from the workflows. Assisted-by: DeepSeek V4 Flash
The copyright symbol was corrupted to U+FFFD when the file was re-saved as UTF-8 without a BOM. Restore it and encode the file as UTF-8 with a BOM so rc.exe decodes it correctly (it assumes ANSI without one); document the exception in .editorconfig. Assisted-by: DeepSeek V4 Flash
Re-running the release workflow appended a second copy of the changelog. Wrap it in a marker block that is stripped before re-appending, and drop the non-existent update_release_body input. Assisted-by: DeepSeek V4 Flash
General-Info referenced a 'v0.5.0.0-beta1' release that doesn't exist (releases use the short form) and claimed nightlies use a development build number that no longer applies (they share the version's savegame ID). Clarify the release vs nightly build type in copilot-instructions. Assisted-by: DeepSeek V4 Flash
Write STR_GIT_COMMIT / STR_GIT_REF / STR_GIT_DIRTY into a generated $(IntDir)Generated\Phobos.Git.h that Phobos.version.h includes, instead of passing /D defines to every translation unit. A changed commit now only rebuilds the few units that include the header (WriteOnlyWhenDifferent keeps no-op builds from churning), instead of all 223. The STR_* values are spelled out directly because rc.exe cannot stringize a file-defined string literal. Assisted-by: DeepSeek V4 Flash
Add the versioning-scheme diagram (from 0.5 onward) to the branching model section, right after the intro, with a footnote pointing to the editable Excalidraw source. Assisted-by: DeepSeek V4 Flash
…defines Include both Debug and Release Generated folders (Phobos.Git.h lands in whichever config is built; cpptools has no predefined Debug/Release variable, so list both). Add the always-present defines from Phobos.props that were missing (_WIN32_WINNT, NTDDI_VERSION, PHOBOS_DLL); keep _WINDLL since MSBuild adds it for the DLL config. DEBUG/NIGHTLY/RELEASE are config-specific and stay out. Assisted-by: DeepSeek V4 Flash
A pre-release whose own heading carries notes is now released as just those notes; an empty or missing heading falls back to the base version it leads up to, instead of appending the tagged subsection and everything below it to the base sections. Also drop the now-unused Version TBD fallback and recognize MyST colon fences alongside backtick and tilde ones. Assisted-by: DeepSeek V4 Flash
|
Contents of Automatic changelog generation probably needs testing, I can try to do that later if no one else has gotten to it by then. |
# Conflicts: # docs/Whats-New.md
…itle to the dropdown
|
@Starkku I was successful with the script already locally in my testing, haven't tried CI |
6 participants
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:
@Metadorius's TODO:
Volunteers needed! this is long overdue, as is "devbuild" release, as is 0.5.