32 Releases 32 Tags

RSS Feed

• v4.4.0 d29d400dd3

  Compare

  v4.4.0 Stable

  torben released this 2026-09-03 20:22:38 +00:00 | 72 commits to main since this release

  4.4.0 - 2026-09-03 - Versionskandidat statt Bump-pro-Release: VERSION traegt -beta.N, version release fixiert

  Author: Torben Nehmer

  • Versionskandidat statt Bump-pro-Release: VERSION traegt -beta.N, version release fixiert

  Bisher bekam jeder version bump sofort eine fixierte Nummer, und weil release.yml auf jede
  VERSION-Bewegung feuert, wurde daraus sofort ein Release: Nummern entstanden in
  Commit-Granularität statt in Release-Granularität. Der 2026-09-03 hat so vier Releases in sechs
  Stunden erzeugt (4.3.0 bis 4.3.3), zwei davon für reine Prosa-Änderungen - alle vier echt,
  keines davon eine Einheit, an der ein Konsument sich hätte orientieren können. VERSION trägt
  jetzt zwischen zwei Releases einen laufenden Kandidaten (X.Y.Z-beta.N):
  --major/--minor/--patch eskaliert diesen Kandidaten max-wins gegen den letzten Release, statt
  eine neue Nummer danebenzustellen, und geht dabei nie zurück.

  Version versteht den Suffix, mit einer expliziten Ordnung
  (4.4.0-beta.1 < 4.4.0-beta.2 < 4.4.0, numerisch nach N, nicht lexikografisch). CHANGES.md
  trägt genau einen offenen Eintrag pro Kandidat: der erste Bump eröffnet ihn, jeder weitere
  aktualisiert Heading und die maschinenverwaltete Bump-Titel-Liste in
  <!-- wikitool:bumps --> (Marker-Konvention aus blocks.py, aber bewusst nicht in
  blocks.BLOCKS - diese Region gehört zu CHANGES.md, nicht zu einer Seite). version release
  ist neu und fixiert einen Kandidaten: Suffix weg, Eintrag geschlossen, committet und pusht nichts.

  Vier Stellen am Bestand angepasst, die das Kandidatenmodell sonst still beschädigt hätten:
  release.yml überspringt einen suffixbehafteten VERSION-Push sauber, bevor die Releases-API
  gefragt wird, statt jeden Beta-Bump zu veröffentlichen; die Grenzübertritts-Checks in
  docs verify (check_migration_for_boundary, check_breaking_change_for_boundary) messen jetzt
  gegen den letzten Release (version_mod.last_release) statt gegen den zweitobersten Eintrag,
  der zwischen zwei Betas keine Grenze mehr hergibt; kb_state.chain()/next_link() vergleichen
  gegen die Kandidatenbasis, weil eine Migration mit Ziel 4.4.0 sonst bei installiertem
  4.4.0-beta.1 aus dem Intervall fällt (4.4.0-beta.1 < 4.4.0); read_kb_version() verweigert
  einen Prerelease, weil eine Inhaltsform kein Beta kennt. dist export schreibt VERSION und den
  Stamp weiterhin ehrlich mit Suffix, aber .wikitool-kb.json bekommt die Basis.

  Menschendoku für die Erzeuger-Seite: DEVELOPMENT.md im Repo-Root, bewusst nicht in
  dist_cmd.ROOT_FILES (Begründung als Kommentar dort), mit Zeile in AGENTS.md § File naming und
  Zeiger aus README.md. docs/version-model.md hat einen neuen Abschnitt, warum eine Nummer erst
  durch ein Release verbraucht wird.

  Downloads

  • chemenu-stack-4.4.0.tar.gz
    485 KiB

    2026-09-03 20:22:39 +00:00
  • chemenu-stack-4.4.0.tar.gz.sha256
    93 B

    2026-09-03 20:22:39 +00:00
  • Source Code (ZIP)
  • Source Code (TAR.GZ)