[cogwright]

irrl asked for year-based versions: 26.2.0-dev.17 as the version, shown as "26.2 Preview 17".

Numbering:

• Releases are numbered by year: the N-th release of 2026 is 26.N.0 (shown "26.N"), and a new year's first is YY.1. A fix to a release is 26.2.1.
• Each push to main builds a preview of the release to come, numbered by main's commits since the last release, as before: after release 26.1, main builds 26.2.0-dev.17.
• Automatic: the next number is worked out, with no manual "next version" field.
• Always increasing, so updates keep working: from today's 0.0.x the next is 26.1, and across a new year 26.4.0-dev.30 is followed by 27.1.0-dev.31.

What changed:

• scripts/next-version.mjs (new): works out main's version from the last release tag and the commit count (nextVersion(lastTag, count, year)). It's plain Node, so the workflow runs it directly; the rule moved out of inline bash so it can be tested.

• .github/workflows/release.yml, the Choose the version step and the two release titles. This doesn't change what the workflow can access: no new permissions, secrets or steps with write access. The release job's write permission and the prerelease job are as they were.

  • A main push gets its version from node scripts/next-version.mjs "$tag" "$count", with the tag and count found as before (git describe --match 'v[0-9]*' --exclude '*-*', git rev-list --count). The version job's runner already has Node.
  • A release tag can be v26.2 or v26.2.0; both make 26.2.0.
  • Titles read as the studio does: drafts "Glist Studio 26.2" (the tag without its v), and prereleases "Glist Studio 26.2 Preview 17". The prerelease cleanup's tag pattern already matches the new versions.

• src/versions.ts (new): versionName shows a release as "26.2" (a fix as "26.2.1") and a preview as "26.2 Preview 17", with the words from the window's language (versionPreview: Preview / Önizleme / Préversion). Anything else, such as the old 0.0.10-dev.40 ("0.0.10 Preview 40"), reads as sensibly as it can.

• Where it shows:

  • Settings > About (the copied text keeps the exact version for reports);
  • the update notices;
  • Settings > Updates' current version and its "went back from" note;
  • the rollback list, where previews now say so in their name, so the separate "Preview" label (rollbackPreview) is gone and releases still say "Release".

  Logs and Copy Debug Info keep the exact version.

• The README describes the numbering.

Kept: the v on git tags. People never see it now (the studio and the release titles drop it), but the workflow's tag trigger, finding the last release and the updater's lookups all use v tags, as every existing tag does.

Verified:

• New tests/versions.test.mjs (in npm test). It covers:

  • the next version after v0.0.9, v26.1, v26.1.0, a fix v26.3.1, a new year, and no release;
  • always newer across the change and a new year;
  • display names for releases, fixes, previews, two-digit minors, the old numbers, Turkish, and anything unrecognised left alone.

  npm test, tsc, lint and the locale test pass.

• In the browser build, with the version set to 26.2.0-dev.17 for the check (reverted): About shows "26.2 Preview 17", and "26.2 Önizleme 17" in Turkish.

• The title shell expressions give "Glist Studio 26.2 Preview 17" for 26.2.0-dev.17 and "26.2.1 Preview 3" for a fix's preview.

Not verified: a real run of the release workflow; that happens on the next push to main after merging. Its first preview will be 26.1.0-dev.<commits since v0.0.9>, which should look like "26.1 Preview N". The first year-based release is then tagged v26.1.

🤖 Generated with Claude Code