Marks dev as ahead of the 2.2.0 release, so tester builds report
2.3.0-dev instead of claiming to be the released version. The final
number is decided when the release is cut - a cycle that turns out to
carry only fixes ships as 2.2.1 instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drop the -dev suffix and date the whatsnew section so release.sh can find
its notes. Also make the build-string example in the whatsnew header read
as an example, instead of naming one particular build that goes stale the
moment it ships.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Marks dev as ahead of the 2.1.0 release, so tester builds report
2.2.0-dev instead of claiming to be the released version. The final
number is decided when the release is cut - a cycle that turns out to
carry only fixes ships as 2.1.1 instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The app already knew exactly which build was running - a calendar version
of commit date plus short hash - but nothing gave a release a name users
could quote, and the repo had no tags at all.
Adds a VERSION file as the single source of truth for a SemVer release
number, read by app/version.py alongside the existing build string rather
than replacing it: the number is for people, the build is for pinning down
a deploy, and both ship in /api/version and the template context. The menu
shows the release first with the build underneath. #versionText still holds
the build string, because the remote-update poller compares it to detect
that the server came back on a new build.
Resolution order is unchanged (frozen file > git > fallback), and a frozen
file written before this change still yields a correct release number, so
an already-deployed server does not need re-freezing to stay sane. The
container has no git, hence COPY VERSION into the image - otherwise a plain
'docker compose build' reports 0.0.0.
scripts/release.sh cuts a release from main: it refuses a dirty tree, a
wrong branch, a malformed number or an existing tag, extracts the notes
from the matching whatsnew section, then tags, pushes and publishes via gh.
Numbering starts at 2.1.0 rather than 1.x: the v2 line has been in
production since March and 'v1' is the archived pre-migration branch, so
1.x would have been ambiguous. Sections in whatsnew before 2.1.0 keep
their date-only headings - they were never tagged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MarekWo