docs: enshrine the fork versioning scheme
Document upstream's vYY.<release-seq>.<patch> scheme (year, sequential release-in-year, patch) in docs/ci-cd.md + CLAUDE.md so we follow it going forward: <release-seq> is NOT the calendar month (v25.2.0 shipped in June, v26.3.0 in Feb), it's a per-year counter that resets each January. v26.3.1 = our infra-only rebuild of upstream 26.3.0; v26.4.0 reserved for the first release with app changes. Also notes the [skip ci]-on-a-tagged-commit gotcha. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -57,6 +57,7 @@ docker build -f docker/Dockerfile -t ersatztv:dev .
|
||||
- Domain logic in `ErsatzTV.Core`, infrastructure in `ErsatzTV.Infrastructure`
|
||||
- Keep Blazor pages thin — delegate to MediatR handlers
|
||||
- Test with xUnit (existing test projects)
|
||||
- **Versioning**: release tags are `vYY.<release-seq>.<patch>` (year · sequential release-within-year · patch) — inherited from upstream, **not** year.month. `v26.3.1` = our infra rebuild of upstream 26.3.0 (no app changes); `v26.4.0` is reserved for the first release with app changes. Never `[skip ci]` a commit you'll tag (it suppresses the release build). Full policy: `docs/ci-cd.md` → Versioning & releases.
|
||||
- Backlog tracked via [Gitea Issues](http://192.168.1.95:3000/timothy/ersatztv/issues)
|
||||
|
||||
## Task Completion Protocol
|
||||
|
||||
@@ -5,6 +5,25 @@ to the **Gitea container registry**. Runner + registry were provisioned in
|
||||
server-management#172; the build pipeline is ersatztv#4; test/prod containers are
|
||||
server-management#481.
|
||||
|
||||
## Versioning & releases
|
||||
|
||||
The fork inherits upstream ErsatzTV's scheme: **`vYY.<release-seq>.<patch>`** (lightweight, `v`-prefixed git tags).
|
||||
|
||||
- **`YY`** — two-digit year.
|
||||
- **`<release-seq>`** — a sequential release counter **within the year**, reset at each year boundary. It is **not** the calendar month. (Evidence: `v25.2.0` shipped in June 2025, `v25.5.0` in Sep, `v26.3.0` in Feb 2026 — minors don't track months; and `v25.9.0` → `v26.1.0` shows the year-reset.)
|
||||
- **`<patch>`** — a small follow-up/hotfix on the *same* release line (e.g. `v26.1.0` → `v26.1.1`, days later).
|
||||
|
||||
Upstream's final release was **`v26.3.0`** (archived). Our line continues from there:
|
||||
|
||||
| Tag | Meaning |
|
||||
|-----|---------|
|
||||
| `v26.3.1` | Upstream 26.3.0 **rebuilt on our infra** (Gitea CI/registry, fork ffmpeg base) — **no application changes**. A patch bump, because nothing functional changed. |
|
||||
| `v26.4.0` | Reserved for our **first release that carries actual app changes** (e.g. the #1 M3U fix). Later 2026 releases: `26.5.0`, `26.6.0`, …; a new year resets to `27.1.0`. |
|
||||
|
||||
**Cutting a release:** push a `vYY.N.P` tag on `main` → CI builds `:prod` + `:<version>` + `:<sha>`; server-management does the prod switch (server-management#481).
|
||||
|
||||
**Gotcha:** never put a `[skip ci]` token in a commit you intend to tag — Gitea reads skip-ci from the *tagged* commit and will **suppress the release build**. (Also, `workflow_dispatch` on a tag ref isn't supported on this Gitea version, so the tag *push* must do the triggering.) Release commits, and anything you'll tag, must not contain skip-ci.
|
||||
|
||||
## The workflow: `.gitea/workflows/docker-build.yml`
|
||||
|
||||
Single workflow, two jobs (`test` → `build`).
|
||||
|
||||
Reference in New Issue
Block a user