You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SwitchCraft follows a strict versioning schema to ensure compatibility, easy identification of release types, and proper upgrade paths. This document describes how version numbers are generated, how CI handles them, and how they map to different artifacts.
4
+
5
+
## Version Number Logic
6
+
7
+
### Base Format
8
+
The core version number follows a calendar-based schema:
9
+
10
+
```
11
+
Year.Month.Release
12
+
```
13
+
14
+
***Year**: The current year (e.g., `2026`).
15
+
***Month**: The current month (e.g., `1` for January).
16
+
***Release**: An incrementing number for releases within that month (e.g., `5`).
17
+
18
+
Example: `2026.1.5`
19
+
20
+
### Release Types (Suffixes)
21
+
Depending on the build type (Stable, Beta, Development), suffixes are appended to the base version:
22
+
23
+
| Release Type | Suffix Example | Full Version Example | Description |
24
+
| :--- | :--- | :--- | :--- |
25
+
|**Stable**|*(None)*|`2026.1.5`| Production-ready official release. |
26
+
|**Beta**|`b{N}`|`2026.1.5b1`| Public test build. Stable enough for testing. |
Windows executables and installers (`.exe`, `.msi`) require a strict 4-part numeric version format (`A.B.C.D`) in their file resources (`VS_VERSION_INFO`).
34
+
35
+
SwitchCraft maps the semantic version to this 4-part numeric format as follows:
36
+
37
+
```
38
+
Year.Month.Release.BuildNumber
39
+
```
40
+
41
+
***Year.Month.Release**: Taken directly from the base version.
42
+
***BuildNumber**: Derived from the **GitHub Actions Run Number** (CI) or a local counter.
43
+
44
+
### Why this matters?
45
+
Windows uses this 4-part version to decide if an installer is an "Upgrade".
46
+
*`2026.1.5.105` > `2026.1.5.100` -> Windows considers this a new version.
47
+
* Stable releases usually have `0` as the build number base, while Dev builds use the Run Number to ensure every CI build is "newer" than the previous one for testing, but "older" than the next Stable release if semver rules apply (though in Windows, `.100` is > `.0`, so Dev builds might appear "newer" than the *same* stable version. We handle this by bumping the `Release` number for Stable).
48
+
49
+
### Local Builds
50
+
When building locally (using `scripts/build_release.ps1`), you can specify a custom build number to test upgrades:
0 commit comments