Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion .github/actions/build-phobos/action.yml
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,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'
runs:
using: "composite"
steps:
Expand All @@ -21,7 +25,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: Upload Artifact
Expand Down
5 changes: 2 additions & 3 deletions .github/workflows/nightly.yml
Original file line number Diff line number Diff line change
Expand Up @@ -3,8 +3,6 @@ name: Nightly Build
on:
push:
branches:
- master
- main
- develop

env:
Expand All @@ -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/}

Expand All @@ -32,3 +30,4 @@ jobs:
with:
sln-path: ${{env.SOLUTION_FILE_PATH}}
build-config: ${{env.BUILD_CONFIGURATION}}
build-type: NIGHTLY
4 changes: 3 additions & 1 deletion .github/workflows/pr-nightly.yml
Original file line number Diff line number Diff line change
Expand Up @@ -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/}

Expand All @@ -29,3 +29,5 @@ jobs:
with:
sln-path: ${{env.SOLUTION_FILE_PATH}}
build-config: ${{env.BUILD_CONFIGURATION}}
build-type: NIGHTLY

63 changes: 63 additions & 0 deletions .github/workflows/release.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
name: Release Build

on:
release:
types: [published]

env:
SOLUTION_FILE_PATH: .
BUILD_CONFIGURATION: Release

permissions:
contents: write

jobs:
build:
runs-on: windows-latest

steps:
- uses: actions/checkout@v6
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
body_path: RELEASE_NOTES.md
7 changes: 2 additions & 5 deletions Phobos.sln
Original file line number Diff line number Diff line change
@@ -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
Expand Down
3 changes: 0 additions & 3 deletions Phobos.vcxproj
Original file line number Diff line number Diff line change
@@ -1,8 +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>
<PropertyGroup Label="Globals">
<ProjectName>Phobos</ProjectName>
<RootNamespace>Phobos</RootNamespace>
Expand Down
2 changes: 1 addition & 1 deletion docs/General-Info.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ 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}
Expand Down
24 changes: 15 additions & 9 deletions docs/Project-guidelines-and-policies.md
Original file line number Diff line number Diff line change
Expand Up @@ -229,15 +229,21 @@ 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 changelog addition; in other words — only bug fixes, minor additions, and polish to the existing feature set are allowed.
- Documentation for the version (e.g., `v0.5`) is created at this point and is shared across all its pre-releases and the final stable release, rather than generating separate docs for each pre-release.
3. **Stable release**: When the pre-release builds are deemed stable enough, a stable release (e.g., `v0.5`) is published from the release 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;
Expand Down
93 changes: 93 additions & 0 deletions scripts/extract_changelog.ps1
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
param(
[Parameter(Mandatory = $true)]
[string]$Tag,

[Parameter(Mandatory = $true)]
[string]$WhatsNewPath,

[Parameter(Mandatory = $true)]
[string]$OutputPath
)

$version = $Tag.TrimStart('v')

if (-not (Test-Path $WhatsNewPath)) {
Write-Error "File not found: $WhatsNewPath"
exit 1
}

$content = (Get-Content -Path $WhatsNewPath -Raw -Encoding utf8) -replace "`r`n", "`n"

$changelogIdx = $content.IndexOf("## Changelog")
if ($changelogIdx -lt 0) {
Write-Error "Could not find '## Changelog' section in $WhatsNewPath"
exit 1
}

$afterChangelog = $content.Substring($changelogIdx + "## Changelog".Length + 1)

$nextSectionIdx = $afterChangelog.IndexOf("`n## ")
$changelogBody = if ($nextSectionIdx -ge 0) { $afterChangelog.Substring(0, $nextSectionIdx) } else { $afterChangelog }

# Try to find the section: exact version -> parent versions -> Version TBD
$sectionStart = -1

# 1) Exact version match
$sectionStart = $changelogBody.IndexOf("### $version`n")

# 2) Strip trailing numeric components until found
if ($sectionStart -lt 0) {
$tryVersion = $version -replace '\.[0-9]+$', ''
while ($tryVersion -ne $version) {
$sectionStart = $changelogBody.IndexOf("### $tryVersion`n")
if ($sectionStart -ge 0) { break }
$version = $tryVersion
$tryVersion = $version -replace '\.[0-9]+$', ''
}
$version = $Tag.TrimStart('v') # restore original
}

# 3) Fall back to Version TBD
if ($sectionStart -lt 0) {
$sectionStart = $changelogBody.IndexOf("### Version TBD")
}

if ($sectionStart -lt 0) {
Write-Error "Could not find changelog section for version '$version' or 'Version TBD'"
exit 1
}

$sectionEnd = $changelogBody.IndexOf("`n### ", $sectionStart + 5)
if ($sectionEnd -ge 0) {
$sectionContent = $changelogBody.Substring($sectionStart, $sectionEnd - $sectionStart)
} else {
$sectionContent = $changelogBody.Substring($sectionStart)
}

$firstNewline = $sectionContent.IndexOf("`n")
if ($firstNewline -ge 0) {
$sectionContent = $sectionContent.Substring($firstNewline + 1)
} else {
$sectionContent = ""
}

$sectionContent = $sectionContent.Trim()

$dropdownPattern = '(?ms)^```\{dropdown\}[^\n]*\n(.+?)^```'
$dropdownMatch = [regex]::Match($sectionContent, $dropdownPattern)

if ($dropdownMatch.Success) {
$sectionContent = $dropdownMatch.Groups[1].Value.Trim()
}

$sectionContent = $sectionContent -replace '(?m)^:open:\s*\n', ''
$sectionContent = $sectionContent.Trim()

if (-not $sectionContent) {
Write-Error "Extracted changelog content is empty for version '$version'"
exit 1
}

$sectionContent | Out-File -FilePath $OutputPath -Encoding utf8

Write-Host "Extracted changelog for version '$version' to '$OutputPath'"
8 changes: 4 additions & 4 deletions src/Phobos.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@
#include "Utilities/AresHelper.h"
#include "Utilities/Parser.h"

#ifndef IS_RELEASE_VER
#ifndef RELEASE
bool HideWarning = false;
#endif

Expand All @@ -31,7 +31,7 @@ bool Phobos::Optimizations::DisableSyncLogging = false;

#ifdef STR_GIT_COMMIT
const wchar_t* Phobos::VersionDescription = L"Phobos nightly build (" STR_GIT_COMMIT L" @ " STR_GIT_BRANCH L"). DO NOT SHIP IN MODS!";
#elif !defined(IS_RELEASE_VER)
#elif !defined(RELEASE)
const wchar_t* Phobos::VersionDescription = L"Phobos development build #" _STR(BUILD_NUMBER) L". Please test the build before shipping.";
Comment on lines +34 to 35
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably requires wording change

#else
//const wchar_t* Phobos::VersionDescription = L"Phobos release build v" FILE_VERSION_STR L".";
Expand Down Expand Up @@ -60,7 +60,7 @@ void Phobos::CmdLineParse(char** ppArgs, int nNumArgs)
{
Phobos::AppIconPath = ppArgs[++i];
}
#ifndef IS_RELEASE_VER
#ifndef RELEASE
if (_stricmp(pArg, "-b=" _STR(BUILD_NUMBER)) == 0)
{
HideWarning = true;
Comment on lines 64 to 66
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Setting aside the writing of the value, does -b itself need to be changed?
  2. 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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-IKnowWhatImDoing

Copy link
Copy Markdown
Collaborator Author

@DeathFishAtEase DeathFishAtEase Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-IKnowWhatImDoing

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

Expand Down Expand Up @@ -233,7 +233,7 @@ DEFINE_HOOK(0x683E7F, ScenarioClass_Start_Optimizations, 0x7)
return 0;
}

#ifndef IS_RELEASE_VER
#ifndef RELEASE
DEFINE_HOOK(0x4F4583, GScreenClass_DrawText, 0x6)
{
#ifndef STR_GIT_COMMIT
Expand Down
36 changes: 18 additions & 18 deletions src/Phobos.version.h
Original file line number Diff line number Diff line change
Expand Up @@ -22,32 +22,32 @@

#pragma endregion

// Build number. Incremented on each released build.
#define BUILD_NUMBER 48
// Pre-release build number. Incremented on each pre-release build.
#define PRERELEASE_NUM 1
Comment on lines +25 to +26
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why bother with such naming issues?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator Author

@DeathFishAtEase DeathFishAtEase Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


// Nightly defines GIT_COMMIT and GIT_BRANCH in GH Actions
// NIGHTLY / PRERELEASE / RELEASE come from compiler option BuildType - used by GH Actions as well

#ifdef IS_RELEASE_VER // Release build metadata
#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 "Release Build " FILE_VERSION_STR
#elif defined(GIT_COMMIT) // Nightly devbuild metadata
#if defined(NIGHTLY)
#define STR_GIT_COMMIT _STR(GIT_COMMIT)
#define STR_GIT_BRANCH _STR(GIT_BRANCH)

#define SAVEGAME_ID ((BUILD_NUMBER << 24) | (BUILD_NUMBER << 12) | (BUILD_NUMBER))
#define FILE_DESCRIPTION "Unstable nightly devbuild of Phobos engine extension"
#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
Comment on lines +34 to +50
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO for myself: look bit more carefully into this

#endif

#endif // VERSION_H
4 changes: 2 additions & 2 deletions src/version.rc
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ ID_VERSION VERSIONINFO
FILEVERSION FILE_VERSION
PRODUCTVERSION FILE_VERSION
FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
#ifndef IS_RELEASE_VER
#ifndef RELEASE
FILEFLAGS VS_FF_PRERELEASE | VS_FF_SPECIALBUILD
#endif

Expand All @@ -29,7 +29,7 @@ BEGIN
VALUE "InternalName", "Phobos.dll\0"
VALUE "OriginalFilename", "Phobos.dll\0"

#ifndef IS_RELEASE_VER
#ifndef RELEASE
VALUE "SpecialBuild", "Testing version. Use at your own risk.\0"
#endif
END
Expand Down
Loading