32 Releases 32 Tags

RSS Feed

• v2.5.0 31662dc3ff

  Compare

  v2.5.0 Stable

  torben released this 2026-09-02 07:20:31 +00:00 | 93 commits to main since this release

  2.5.0 - 2026-09-02 - Versionsstelle: Kompatibilitaet statt Inhaltsmigration, Breaking-Change-Vermerk erzwungen

  Author: Torben Nehmer

  Die Doku des Stacks führte für die Wahl der Versionsstelle zwei Fragen zusammen, die nicht
  dieselbe sind: muss der Korpus migriert werden? und ist die neue Version ein
  Drop-in-Ersatz? An allen drei Stellen, die einer Session vor dem Bump begegnen - die Tabelle
  in stack-dev, der Modul-Docstring in version.py, INSTALL.md § Version und Updates -
  stand nur die erste. Nur version bump --help formulierte es richtig, also ausgerechnet die
  Stelle, die man erst liest, wenn die Entscheidung gefallen ist. Bei 2.0.0 hat genau diese
  Lücke zu 1.9.0 geführt (Gitea #26; der Eintrag zu 2.0.0 trägt den Fall im Volltext).

  Die Regel, jetzt an einer Stelle. Neu ist
  instructions/dev/version-parts.md: der Drop-in-Test in zwei Hälften - vorwärts (kopieren,
  fertig, keine Handarbeit durch Nutzer oder Migrationsskript) und rückwärts (die alte Version
  lässt sich noch zurückinstallieren) -, der Katalog der Brüche, die die Grenze bei völlig
  unangetastetem kb/ überschreiten (Update-Pfad, Artefaktname, Import-Name, Flags, Envvars,
  Shape maschinengelesener Dateien), und der Fall 2.0.0 als Fallbeispiel. instructions/dev/,
  also nicht in einer ausgelieferten Instanz - die Datei entscheidet, wer den Stack entwickelt.
  Die ausgelieferten Artefakte tragen deshalb die Kurzform der Regel, aber keinen Verweis auf
  sie: instructions verify meldet einen solchen Verweis, weil er nach dist export ins Leere
  zeigen würde.

  Breaking Changes sind teuer, also genehmigungspflichtig. stack-dev hat einen
  Entscheidungspunkt bekommen: stellt sich eine Änderung als nicht drop-in heraus, wird nicht
  aus eigener Initiative über die Grenze gebumpt. Vorgelegt werden der konkrete Bruch, was jede
  bestehende Instanz von Hand tun muss, und die Alternativen - Bruch per Shim vermeiden,
  aufschieben und mit dem nächsten bündeln, oder in einen kompatiblen und einen brechenden Teil
  mit Deprecation-Fenster spalten -, dazu eine Empfehlung. Dann Freigabe abwarten.

  --breaking ist neu und bei jedem Grenzübertritt Pflicht. Es schreibt eine
  **Breaking Change:**-Zeile in den Eintrag, vor die Migrationszeile: das ist, was der Operator
  einer bestehenden Instanz beim Lesen der Release-Notes zuerst braucht. docs verify prüft den
  neuesten grenzüberschreitenden Eintrag darauf, analog zu **Migration:** none required und aus
  demselben Grund - eine Prosa-Regel driftet, ein Marker nicht. Auf einem kompatiblen Bump wird
  --breaking verweigert, damit es keine Gewohnheit wird. Beide Prüfungen bleiben getrennt:
  check_migration_for_boundary fragt, ob der Inhalt sich bewegt, check_breaking_change_for_boundary,
  ob dem Operator gesagt wurde, dass der Tausch keiner zum Drüberkopieren ist. Ein Rebranding
  besteht die erste und fällt durch die zweite.

  Was ausdrücklich nicht passiert: docs verify prüft weiterhin nicht, ob die Stelle
  richtig gewählt wurde. Kein Validator unterscheidet ein umbenanntes Flag von einem neuen; das
  bleibt Urteil, und dieser Eintrag existiert, weil das Urteil eine Anleitung braucht, keinen
  Automaten.

  Berührt: instructions/dev/version-parts.md (neu), instructions/dev/stack-dev/SKILL.md,
  tools/chemenu/version.py, tools/chemenu/commands/version_cmd.py,
  tools/chemenu/commands/docs_verify.py, tools/CONTRACT.md, INSTALL.md. Sechs neue Tests.

  Downloads

  • chemenu-stack-2.5.0.tar.gz
    415 KiB

    2026-09-02 07:20:31 +00:00
  • chemenu-stack-2.5.0.tar.gz.sha256
    93 B

    2026-09-02 07:20:31 +00:00
  • Source Code (ZIP)
  • Source Code (TAR.GZ)