boredos_mirror/docs/architecture/versioning.md

110 lines
3.8 KiB
Markdown

# BoredOS Versioning
BoredOS uses two independent version numbers: one for the **OS release** and one for the **kernel**. They evolve at different rates and follow different conventions.
---
## OS Version
The OS version follows a **date-based** scheme:
```
YY.M[.x]
```
| Component | Meaning |
|-----------|---------|
| `YY` | Two-digit year (e.g. `26` for 2026) |
| `M` | Month number, no leading zero (e.g. `4` for April, `12` for December) |
| `.x` | Optional patch identifier — a small sequential integer that has **no relation to a specific day** |
### Examples
| Version | Meaning |
|----------|---------|
| `26.4` | Base release for April 2026 |
| `26.5` | Base release for May 2026 |
| `26.5.1` | First patch on top of the May 2026 release |
| `26.5.2` | Second patch on top of the May 2026 release |
| `26.12` | Base release for December 2026 |
### Rules
- The **base release** (`YY.M`) is cut once per month when a milestone is ready.
- Patch releases (`YY.M.x`) are issued for fixes or smaller additions that land between two monthly milestones. The `.x` counter starts at `1` and increments sequentially — it is **not** tied to a calendar day.
- A `-dev` or `-rc` suffix may be appended to any version string during active development (e.g. `26.5-dev`, `26.5.1-rc1`).
- The version string is defined in [`src/core/version.c`](../../src/core/version.c) as `os_version`.
---
## Kernel Version
The kernel version follows **Semantic Versioning**:
```
MAJOR.MINOR.PATCH
```
| Component | When to increment |
|-----------|------------------|
| `MAJOR` | A breaking or fundamentally large architectural change (e.g. rewriting the syscall layer, introducing a new memory model) |
| `MINOR` | A meaningful new feature or a notable internal improvement that does not break existing interfaces |
| `PATCH` | A small fix, refactor, or incremental improvement |
### Examples
| Transition | Reason |
|---------------------|--------|
| `4.2.0``5.0.0` | Major kernel rework (e.g. full syscall dispatch-table refactor, new scheduler) |
| `4.2.0``4.3.0` | New subsystem or feature addition (e.g. adding Lua runtime, new VFS driver) |
| `4.2.0``4.2.1` | Small fix or minor tweak (e.g. PIT calibration fix, terminal newline correction) |
### Rules
- When `MAJOR` is bumped, `MINOR` and `PATCH` reset to `0`.
- When `MINOR` is bumped, `PATCH` resets to `0`.
- A `-dev` suffix may be appended during active development (e.g. `5.0.0-dev`).
- The version string is defined in [`src/core/version.c`](../../src/core/version.c) as `kernel_version`.
---
## Where Versions Are Declared
Both version strings live in a single file:
```c
// src/core/version.c
const char *os_version = "26.5-dev";
const char *kernel_version = "4.2.0-dev";
```
When cutting a release, update both strings, remove the `-dev` suffix, tag the commit (`git tag v26.5`), and then immediately bump to the next `-dev` version.
---
## Codename
Each release may carry an informal **codename**. A single word that gives the release a human-friendly identity. Codenames are stored in [`src/core/version.c`](../../src/core/version.c) as `os_codename` and exposed to userspace via the `get_os_info` syscall.
### Convention
- Codenames **generally change with each monthly base release** (`YY.M`), but this is not a hard rule. A codename may carry over into the next month if the release feels like a natural continuation of the previous one.
- Patch releases (`YY.M.x`) **always keep the same codename** as the base release they belong to.
- There is no enforced theme, but names tend to be short, memorable single words.
### Examples
| OS Version | Codename
|------------|-----------|
| `26.4` | Voyager
| `26.5` | Genesis
### Where It Is Declared
```c
// src/core/version.c
const char *os_codename = "Genesis";
```