Version Management for release 0.5 and Beyond

.github/actions/build-phobos/action.yml

@@ -8,6 +8,10 @@ inputs:
   build-config:
     description: 'Configuration to build'
     required: true
+  build-type:
+    description: 'Build type e.g nightly, prerelease or release'
+    required: true
+    default: 'NIGHTLY'
   syringeex-tag:
     description: 'SyringeEx release tag to bundle (empty for the latest release)'
     required: false
@@ -26,7 +30,7 @@ runs:
     working-directory: ${{env.GITHUB_WORKSPACE}}
     # Add additional options to the MSBuild command line here (like platform or verbosity level).
     # See https://docs.microsoft.com/visualstudio/msbuild/msbuild-command-line-reference
-    run: msbuild /m /p:Configuration=${{inputs.build-config}} /p:GitCommit=${{github.sha}} /p:GitBranch=${{github.ref}} ${{inputs.sln-path}}
+    run: msbuild /m /p:Configuration=${{inputs.build-config}} /p:GitCommit=${{github.sha}} /p:GitBranch=${{github.ref}} /p:BuildType=${{inputs.build-type}} ${{inputs.sln-path}}
     shell: cmd
 
   - name: Stage exception database

.github/workflows/nightly.yml

@@ -3,8 +3,6 @@ name: Nightly Build
 on:
   push:
     branches:
-    - master
-    - main
     - develop
 
 env:
@@ -14,7 +12,7 @@ env:
   # Configuration type to build.
   # You can convert this to a build matrix if you need coverage of multiple configuration types.
   # https://docs.github.com/actions/learn-github-actions/managing-complex-workflows#using-a-build-matrix
-  BUILD_CONFIGURATION: DevBuild
+  BUILD_CONFIGURATION: Release
   # GIT_COMMIT: $(git rev-parse --short "$GITHUB_SHA")
   # GIT_BRANCH: ${GITHUB_REF#refs/heads/}
 
@@ -32,3 +30,4 @@ jobs:
       with:
         sln-path: ${{env.SOLUTION_FILE_PATH}}
         build-config: ${{env.BUILD_CONFIGURATION}}
+        build-type: NIGHTLY

.github/workflows/pr-nightly.yml

@@ -10,7 +10,7 @@ env:
   # Configuration type to build.
   # You can convert this to a build matrix if you need coverage of multiple configuration types.
   # https://docs.github.com/actions/learn-github-actions/managing-complex-workflows#using-a-build-matrix
-  BUILD_CONFIGURATION: DevBuild
+  BUILD_CONFIGURATION: Release
   # GIT_COMMIT: $(git rev-parse --short "$GITHUB_SHA")
   # GIT_BRANCH: ${GITHUB_REF#refs/heads/}
 
@@ -30,3 +30,5 @@ jobs:
       with:
         sln-path: ${{env.SOLUTION_FILE_PATH}}
         build-config: ${{env.BUILD_CONFIGURATION}}
+        build-type: NIGHTLY
+

.github/workflows/release.yml

@@ -0,0 +1,66 @@
+name: Release Build
+
+on:
+  release:
+    types: [published]
+
+env:
+  SOLUTION_FILE_PATH: .
+  BUILD_CONFIGURATION: Release
+
+permissions:
+  contents: write
+
+jobs:
+  build:
+    runs-on: windows-2022
+
+    steps:
+    - uses: actions/checkout@v7
+      with:
+        submodules: recursive
+
+    - name: Determine Build Type and Version Info
+      id: info
+      shell: pwsh
+      run: |
+        $tag = "${{ github.ref_name }}"
+        $version = $tag.TrimStart('v')
+        $isPrerelease = "${{ github.event.release.prerelease }}"
+        if ($isPrerelease -eq "true") {
+          $buildType = "PRERELEASE"
+          $releaseName = "Phobos $tag (Pre-release)"
+        } else {
+          $buildType = "RELEASE"
+          $releaseName = "Phobos $tag"
+        }
+        echo "build-type=$buildType" >> $env:GITHUB_OUTPUT
+        echo "version=$version" >> $env:GITHUB_OUTPUT
+        echo "release-name=$releaseName" >> $env:GITHUB_OUTPUT
+
+    - name: Build Phobos
+      uses: ./.github/actions/build-phobos
+      with:
+        sln-path: ${{env.SOLUTION_FILE_PATH}}
+        build-config: ${{ env.BUILD_CONFIGURATION }}
+        build-type: ${{ steps.info.outputs.build-type }}
+
+    - name: Extract Changelog
+      shell: pwsh
+      run: |
+        .\scripts\extract_changelog.ps1 `
+          -Tag "${{ github.ref_name }}" `
+          -WhatsNewPath docs\Whats-New.md `
+          -OutputPath RELEASE_NOTES.md
+
+    - name: Upload Release Assets
+      uses: softprops/action-gh-release@v2
+      with:
+        name: ${{ steps.info.outputs.release-name }}
+        files: |
+          ${{ env.BUILD_CONFIGURATION }}/Phobos.dll
+          ${{ env.BUILD_CONFIGURATION }}/Phobos.pdb
+          ${{ env.BUILD_CONFIGURATION }}/gamemd.edb
+          ${{ env.BUILD_CONFIGURATION }}/Syringe.exe
+          ${{ env.BUILD_CONFIGURATION }}/Syringe.LICENSE.txt
+        body_path: RELEASE_NOTES.md

Phobos.props

@@ -5,10 +5,6 @@
       <Configuration>Debug</Configuration>
       <Platform>Win32</Platform>
     </ProjectConfiguration>
-    <ProjectConfiguration Include="DevBuild|Win32">
-      <Configuration>DevBuild</Configuration>
-      <Platform>Win32</Platform>
-    </ProjectConfiguration>
     <ProjectConfiguration Include="Release|Win32">
       <Configuration>Release</Configuration>
       <Platform>Win32</Platform>
@@ -70,21 +66,6 @@
   </ItemDefinitionGroup>
   <!-- Release -->
   <ItemDefinitionGroup Condition="$(Configuration.Contains('Release'))">
-    <ClCompile>
-      <PreprocessorDefinitions>IS_RELEASE_VER;%(PreprocessorDefinitions)</PreprocessorDefinitions>
-      <Optimization>MaxSpeed</Optimization>
-      <OmitFramePointers>true</OmitFramePointers>
-      <!-- <WholeProgramOptimization>true</WholeProgramOptimization> -->
-    </ClCompile>
-    <Link>
-      <!-- <LinkTimeCodeGeneration>UseLinkTimeCodeGeneration</LinkTimeCodeGeneration> -->
-    </Link>
-    <ResourceCompile>
-      <PreprocessorDefinitions>IS_RELEASE_VER;%(PreprocessorDefinitions)</PreprocessorDefinitions>
-    </ResourceCompile>
-  </ItemDefinitionGroup>
-  <!-- DevBuild -->
-  <ItemDefinitionGroup Condition="$(Configuration.Contains('DevBuild'))">
     <ClCompile>
       <Optimization>MaxSpeed</Optimization>
       <OmitFramePointers>true</OmitFramePointers>
@@ -124,6 +105,31 @@
       <AdditionalOptions>/DGIT_BRANCH="$(GitBranch)" %(AdditionalOptions)</AdditionalOptions>
     </ResourceCompile>
   </ItemDefinitionGroup>
+  <!-- BuildType -->
+  <ItemDefinitionGroup Condition="'$(BuildType)' == 'NIGHTLY'">
+    <ClCompile>
+      <PreprocessorDefinitions>NIGHTLY;%(PreprocessorDefinitions)</PreprocessorDefinitions>
+    </ClCompile>
+    <ResourceCompile>
+      <PreprocessorDefinitions>NIGHTLY;%(PreprocessorDefinitions)</PreprocessorDefinitions>
+    </ResourceCompile>
+  </ItemDefinitionGroup>
+  <ItemDefinitionGroup Condition="'$(BuildType)' == 'PRERELEASE'">
+    <ClCompile>
+      <PreprocessorDefinitions>PRERELEASE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
+    </ClCompile>
+    <ResourceCompile>
+      <PreprocessorDefinitions>PRERELEASE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
+    </ResourceCompile>
+  </ItemDefinitionGroup>
+  <ItemDefinitionGroup Condition="'$(BuildType)' == 'RELEASE'">
+    <ClCompile>
+      <PreprocessorDefinitions>RELEASE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
+    </ClCompile>
+    <ResourceCompile>
+      <PreprocessorDefinitions>RELEASE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
+    </ResourceCompile>
+  </ItemDefinitionGroup>
   <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
   <ImportGroup Label="ExtensionTargets" />
 </Project>

Phobos.sln

@@ -1,21 +1,18 @@
 
 Microsoft Visual Studio Solution File, Format Version 12.00
-# Visual Studio Version 16
-VisualStudioVersion = 16.0.29209.62
+# Visual Studio Version 18
+VisualStudioVersion = 18.4.11626.88 stable
 MinimumVisualStudioVersion = 10.0.40219.1
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Phobos", "Phobos.vcxproj", "{3FAF7126-F38C-4D1E-9973-C21A37870F60}"
 EndProject
 Global
 	GlobalSection(SolutionConfigurationPlatforms) = preSolution
 		Debug|x86 = Debug|x86
-		DevBuild|x86 = DevBuild|x86
 		Release|x86 = Release|x86
 	EndGlobalSection
 	GlobalSection(ProjectConfigurationPlatforms) = postSolution
 		{3FAF7126-F38C-4D1E-9973-C21A37870F60}.Debug|x86.ActiveCfg = Debug|Win32
 		{3FAF7126-F38C-4D1E-9973-C21A37870F60}.Debug|x86.Build.0 = Debug|Win32
-		{3FAF7126-F38C-4D1E-9973-C21A37870F60}.DevBuild|x86.ActiveCfg = DevBuild|Win32
-		{3FAF7126-F38C-4D1E-9973-C21A37870F60}.DevBuild|x86.Build.0 = DevBuild|Win32
 		{3FAF7126-F38C-4D1E-9973-C21A37870F60}.Release|x86.ActiveCfg = Release|Win32
 		{3FAF7126-F38C-4D1E-9973-C21A37870F60}.Release|x86.Build.0 = Release|Win32
 	EndGlobalSection

Phobos.vcxproj

@@ -1,23 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
 <Project DefaultTargets="Build" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-  <PropertyGroup>
-    <ShowAllFiles>true</ShowAllFiles>
-  </PropertyGroup>
-  <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
-    <ClCompile>
-      <MultiProcessorCompilation>true</MultiProcessorCompilation>
-    </ClCompile>
-  </ItemDefinitionGroup>
-  <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='DevBuild|Win32'">
-    <ClCompile>
-      <MultiProcessorCompilation>true</MultiProcessorCompilation>
-    </ClCompile>
-  </ItemDefinitionGroup>
-  <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
-    <ClCompile>
-      <MultiProcessorCompilation>true</MultiProcessorCompilation>
-    </ClCompile>
-  </ItemDefinitionGroup>
   <PropertyGroup Label="Globals">
     <ProjectName>Phobos</ProjectName>
     <RootNamespace>Phobos</RootNamespace>

docs/General-Info.md

@@ -6,18 +6,18 @@ This page lists general info that should be known about the project.
 
 There are three main types of Phobos builds:
 - *stable builds* - those are numbered like your regular versions (something close to semantic versioning, e.g. version 1.2.3 for example) and ideally should contain no bugs, therefore are safe to use in mods;
-- *development builds* - those are the builds which contain functionality that needs to be tested. They are numbered plainly starting from 0 and incrementing the number on each release. Mod authors still can include those versions with their mods if they want latest features, though we can't guarantee lack of bugs;
+- *pre-release builds* - previously known as *development builds*, these builds mark the start of a new release branch and are used for testing new features before they are finalized. They are numbered with a version and a pre-release suffix (e.g., 0.5-beta1, 0.5-rc2). Mod authors can include these versions with their mods to access the latest features, but we cannot guarantee the absence of bugs;
 - *nightly builds* - bleeding edge versions which can include prototypes, proofs of concepts, scrapped features etc., in other words - we can't guarantee anything in those builds and they absolutely should NOT be used in mod releases and should only be used to help with development and testing.
 
 ```{hint}
 You can find the downloads for these versions on the document's [main page](index.md#downloads).
 ```
 
-### Disabling development build warning
+### Disabling pre-release build warning
 
-**DISCLAIMER:** We understand that everyone wants to try and use the new features as soon as they're released, but we can't do all the testing ourselves, so we only test the functionality on a basic level. We ask everyone who uses the new development build first to **test the new changes in every possible way first before disabling the development build warning** and proceeding to include the build in your mod release. This would allow us to concentrate on implementing the actual features, which is the most complex task. Learn more on testing [here](Contributing.md#testing).
+**DISCLAIMER:** We understand that everyone wants to try and use the new features as soon as they're released, but we can't do all the testing ourselves, so we only test the functionality on a basic level. We ask everyone who uses the new pre-release build first to **test the new changes in every possible way first before disabling the pre-release build warning** and proceeding to include the build in your mod release. This would allow us to concentrate on implementing the actual features, which is the most complex task. Learn more on testing [here](Contributing.md#testing).
 
-You can hide the warning by specifying the build number after `-b=` as a command line argument (for example, `-b=1` would hide the warning for development build #1 of Phobos).
+You can hide the warning by specifying the exact version of the build you use after `-HideVersionWarning=` as a command line argument (for example, `-HideVersionWarning=0.5-beta1` would hide the warning for the `v0.5-beta1` pre-release of Phobos). The version is shown in the warning itself and in the title of the respective release; a build only accepts its own version, so the switch has to be updated whenever you update Phobos. Nightly builds don't support hiding the warning at all.
 
 ## Saved games filtering
 

docs/Project-guidelines-and-policies.md

@@ -230,15 +230,20 @@ DEFINE_HOOK(0x48381D, CellClass_SpreadTiberium_CellSpread, 0x6)
 The styleguide is not exhaustive and may be adjusted in the future.
 ```
 
-## Git branching model
-
-Couple of notes regarding the Git practices. We use [git-flow](https://nvie.com/posts/a-successful-git-branching-model/)-like workflow:
-  - `master` is for stable releases, can have hotfixes pushed to it or branched off like a feature branch with the requirement of version increment and `master` being merged into `develop` after that;
-  - `develop` is the main development branch;
-  - `feature/`-prefixed branches (sometimes the prefix may be different if appropriate, like for big fixes or changes) are so called "feature branches" - those are branched off `develop` for every new feature to be introduced into it and then merged back. We use squash merge to merge them back in case of smaller branches and sometimes merge commit in case the branch is so big it would be viable to keep it as is.
-  - `hotfix/`-prefixed branches may be used in a same manner as `feature/`, but with `master` branch, with a requirement of `master` being merged into `develop` after `hotfix/` branch was squash merged into `master`.
-  - `release/`-prefixed branches are branched off `develop` when a new stable release is slated to allow working on features for a next release and stability improvements for this release. Those are merged with a merge commit into `master` and `develop` with a stable version number increase, after which the stable version is released.
-- When you're working with your local & remote branches use **fast-forward** pulls to get the changes from remote branch to local, **don't merge remote branch into local and vice versa**, this creates junk commits and makes things unsquashable.
+## Git branching model / Version lifecycle and release strategy
+
+Starting from version 0.5, Phobos adopts a new release strategy to enable faster and more frequent releases. The lifecycle of a version is as follows:
+
+1. **Development phase**: New features and changes are committed to the `develop` branch.
+2. **Pre-release phase**: When enough features have accumulated on `develop`, a pre-release build (e.g., `v0.5-beta1`) is created. This build marks the start of a new *release branch* (e.g., `release/v0.5`) and signifies that active feature development for version 0.5 is complete. This branch will be used for all subsequent testing and the final stable release.
+   - During this phase, multiple pre-release builds (which can be called beta, alpha, or release candidate) may be published for wider testing. Between pre-releases on the same branch, there shall be no changes that warrant a stable version changelog addition; in other words — only bug fixes, minor additions, and polish to the existing feature set are allowed.
+3. **Stable release**: When the pre-release builds are deemed stable enough, a stable release (e.g., `v0.5`) is published from the release's branch.
+4. **Maintenance phase**: After the stable release, the release branch enters maintenance mode, where only bug fixes are applied, resulting in patch releases (e.g., `v0.5.0.1`, `v0.5.0.2`).
+5. **End of maintenance**: When a new stable release is published (e.g., `v0.6`), the previous minor version branch (e.g., `v0.5.0.x`) is officially deprecated and enters end-of-life, ceasing to receive any further updates, including bug fixes. Concurrently, the new stable release (e.g., `v0.6`) enters its own maintenance phase, and a new release branch for the next version (e.g., `release/v0.7`) may already have been created from the `develop` branch, initiating its pre-release cycle.
+
+```{important}
+The `master` branch is deprecated; all development occurs in `develop`, and each version branches off from it.
+```
 
 These commands will do the following for all repositories on your PC:
 1) remove the automatic merge upon pull and replace it with a rebase;