enhancement
major
minor
defect
critical
major
minor
major
#30104
Nächtliche Vorschau-Versionen der Engine mit fester Maven-Version und Änderungsliste statt eines wandernden SNAPSHOT
Kontext
Projekte, die auf dem Entwicklungsstand der Engine aufbauen (z.B. die Steueranwendung TopLogic/tl-factory), hängen von 8.0.0-SNAPSHOT ab. Dieser Stand ändert sich unbemerkt: mvn -U holt, was master zuletzt gebaut hat. Welche Tickets hinzugekommen sind und welche Anpassungen sie verlangen, ist nicht ersichtlich. Ein Bruch zeigt sich erst im Build oder in der laufenden Anwendung.
Beispiel: Mit dem Snapshot vom 31.10.2026 entfielen CommitSource (#29952) und der Anker system-separator der Shell app.view.xml. Ermittelt wurde das erst über einen fehlschlagenden Test bzw. eine Prüfung im Browser.
Der nächtliche Build TL7 baut und testet master bereits vollständig und setzt dabei das Tag BUILD/BUILD-<n>. Feste Maven-Versionen gibt es aber nur für die alpha-Releases, weil eine Version in den pom.xml bisher einen Commit auf master bedeutete. Das soll vermieden werden, damit die Historie der POMs nicht jede Nacht wächst.
Verbesserung
Nach jedem grünen nächtlichen Build (und auf Anforderung für ein beliebiges Build-Tag) wird eine Vorschau-Version mit fester Maven-Version im Release-Repository des Nexus veröffentlicht, zusammen mit der Liste der seit der vorigen Vorschau-Version hinzugekommenen Tickets und ihrer Migrationshinweise. Ein abhängiges Projekt pinnt eine Vorschau-Version (<tl.version>8.0.0-alpha12.813</tl.version>); Renovate schlägt die nächste vor. Ein Versionswechsel ist damit ein bewusster Schritt mit bekannten Tickets und Anpassungen. Bricht er etwas, liegt die Ursache zwischen zwei bekannten Tags.
Lösung
Versionsschema
<X.Y.Z>-alpha<N>.<n>:
- X.Y.Z ist die Version von master ohne -SNAPSHOT.
- N` ist das höchste alpha-Release dieser Version (Tag `TL_X.Y.Z-alpha<N>), 0, solange es noch keines gibt.
- n` ist die Nummer des Build-Tags `BUILD/BUILD-<n>, aus dem die Version gebaut wird. Sie ist eindeutig (auch bei mehreren Builds an einem Tag) und führt direkt zum gebauten Stand.
Nach ComparableVersion von Maven (geprüft mit 3.9.16) sortiert das richtig, auch nach dem Release 8.0.0, wenn master auf 8.1.0-SNAPSHOT steht:
8.0.0-alpha12 < 8.0.0-alpha12.813 < 8.0.0-alpha13 < 8.0.0 < 8.1.0-alpha0.820 < 8.1.0-alpha1 < 8.1.0
Die 0` ist nötig: `8.1.0-alpha.820 sortiert hinter 8.1.0-alpha1. Ein unbekannter Qualifier wie 8.0.0-preview.813 sortiert hinter 8.0.0. Da Vorschau-Versionen Vorabversionen sind, schlägt Renovate sie einem Projekt auf einer stabilen Version nicht vor.
Veröffentlichung ohne Commit auf master (tl-ci)
- Der Job tl-ci-release (Repository tl-ci, release/Jenkinsfile, scripts/release.sh) hat die Parameter PREVIEW und PREVIEW_RETENTION_DAYS (Standard 56). Mit PREVIEW veröffentlicht er das Build-Tag FROM_TAG (BUILD/BUILD-<n>) als Vorschau-Version: release:prepare des maven-release-plugin auf einem lokalen Arbeits-Branch am Build-Tag mit pushChanges=false (dieselbe Mechanik wie bei den alpha-Releases, einschließlich der Property tl.version in tl-bom), release:perform mit localCheckout aus dem lokalen Stand, danach wird nur das Tag gepusht. Tests laufen nicht erneut, sie liefen im nächtlichen Build. Kein Branch des Repositorys ändert sich; master bleibt bei X.Y.Z-SNAPSHOT.
- Tag: PREVIEW/TL_<version>, z.B. PREVIEW/TL_8.0.0-alpha12.813. Es enthält genau die veröffentlichten Quellen. Der eigene Namensraum hält die Vorschau-Versionen aus den Suchen nach Release-Tags (TL_*) heraus. Existiert das Tag schon, endet der Job erfolgreich ohne Build.
- Der nächtliche Build TL7 startet tl-ci-release nach einem erfolgreichen Build mit FROM_TAG=BUILD/BUILD-<n> und PREVIEW=true. Auf Anforderung lässt sich tl-ci-release ebenso für ein beliebiges Build-Tag starten.
- Schlägt nach dem Deploy die Änderungsliste, das Gitea-Release oder das Aufräumen fehl, wird der Build instabil (die Version ist dann bereits veröffentlicht).
Änderungsliste
Je Vorschau-Version ein Gitea-Pre-Release am Tag, https://git.top-logic.com/TopLogic/tl-engine-7/releases/tag/PREVIEW/TL_<version>. Es listet die Tickets aus den Commits seit der vorigen Vorschau-Version (ohne vorige Vorschau-Version: seit dem letzten Release-Tag) mit Typ und Zusammenfassung aus Trac, die Abhängigkeits-Aktualisierungen (DependencyUpdate) gesondert. Die Abschnitte == Migration == der Tickets mit dem Schlüsselwort RequiresMigration stehen voran, von Trac-WikiFormatting nach Markdown umgesetzt. Erzeugt wird die Liste vom Unterkommando tl-release preview-notes --since <rev> --until <rev> des Werkzeugs tl-release (Repository tl-dev-mcp), das die Ticket-Ermittlung der Releases wiederverwendet. Das Trac-Konto liest der Job aus dem Jenkins-Credential tl-ci-trac (Benutzername mit Passwort), das er nur für Vorschau-Releases als TRAC_USERNAME / TRAC_PASSWORD bindet.
Renovate verlinkt die Änderungsliste über prBodyNotes im Pull Request; der Entwicklerartikel application-project (Abschnitt Building on the development state: preview versions) beschreibt die Verwendung einer Vorschau-Version und die Renovate-Konfiguration (ignoreUnstable: false, damit Renovate auch über X.Y.Z hinweg zur nächsten Vorschau-Version wechselt).
Anpassungshinweise
Es gilt die bestehende Konvention der Releases: Ein Ticket, das eine API oder Konfiguration inkompatibel ändert, beschreibt in einem Abschnitt == Migration == seiner Beschreibung, was ein abhängiges Projekt ändern muss, und trägt das Schlüsselwort RequiresMigration.
Aufräumen
Vorschau-Tags und ihre Gitea-Releases werden nach 8 Wochen (PREVIEW_RETENTION_DAYS) gelöscht. Im Nexus entfernt eine Cleanup-Policy die Vorschau-Versionen nach derselben Frist.
Voraussetzungen auf den Jenkins-Knoten
uv/`uvx`, xmllint, python3 und curl. uv ist per pipx für den Benutzer jenkins installiert; die Knoten-Variable PATH+LOCAL=/var/lib/jenkins/.local/bin macht es den Builds zugänglich.