Release-Kanäle
Stable-, Canary- und LTS-dist-tags, synchrone Versionen, Herkunftsnachweise und Releases erstellen.
Text.js erscheint unter drei npm-Dist-Tags. Alle Pakete (@textjs/app, @textjs/react, @textjs/core, @textjs/font, @textjs/opencode, create-text-app und eslint-plugin-textjs) werden im Gleichschritt versioniert, sodass eine Versionsnummer das gesamte Framework beschreibt.
Kanäle
| Kanal | dist-tag | Version | Installation |
|---|---|---|---|
| Stable | latest | 1.0.x | bun add @textjs/app |
| Canary | canary | 1.0.x-canary.N | bun add @textjs/app@canary |
| LTS | lts, v1-lts | Erscheint, sobald 2.0.0 veröffentlicht wird | bun add @textjs/app@lts |
Verwende Stable in der Produktion. Verwende Canary, um Fehlerbehebungen und Funktionen an dem Tag auszuprobieren, an dem sie in dev landen. Sobald es eine LTS-Linie gibt, verwende sie, wenn du einmal im Jahr aktualisierst.
bun create text-app@canary my-consoleStable
Stable-Releases folgen der semantischen Versionierung: Patch-Versionen beheben Fehler, Minor-Versionen ergänzen abwärtskompatible Funktionen, Major-Versionen können nach einer Abkündigungsfrist API-Inkompatibilitäten einführen. Ein Stable-Release entsteht aus einer Canary-Version, die die vollständige Testsuite bestanden hat, und wird mit npm-Herkunftsnachweis veröffentlicht.
Canary
Jeder Push auf dev im offiziellen Repository durchläuft eine Typprüfung und Tests und wird als nächste Patch-Version mit dem Suffix -canary.N veröffentlicht:
latest | Push auf dev | Veröffentlicht |
|---|---|---|
1.0.0 | erster | 1.0.1-canary.0 |
1.0.0 | zweiter | 1.0.1-canary.1 |
1.0.1 | nächster | 1.0.2-canary.0 |
N zählt ab der höchsten bereits auf npm vorhandenen Canary-Version weiter, sodass sich Nummern nie wiederholen. Canary-Versionen werden nicht ins Repository committet. Füge [skip canary] zu einer Commit-Nachricht hinzu, um ein Release zu überspringen.
Canaries sind Builds von dev, dem Branch, in den jeder Pull-Request gemergt wird. Sie können unveröffentlichte APIs ohne Ankündigung ändern oder entfernen. Lege eine exakte Canary-Version fest, wenn du von einer abhängst.
Herkunftsnachweis
Releases werden aus GitHub Actions mit npm publish --provenance veröffentlicht, wodurch jeder Tarball mit genau dem Commit und Workflow verknüpft wird, aus denen er erstellt wurde. Prüfe ein Paket mit:
npm audit signaturesEin Release erstellen
Maintainer erhöhen die Versionen aller Workspace-Pakete im Gleichschritt mit den Release-Skripten:
bun run release:version minor # 1.0.0 → 1.1.0 (also: patch, major, canary, stable, x.y.z)bun run release:publish --tag latest --provenancerelease:version schreibt jede package.json und die zugehörigen Versionskonstanten (VERSION, rendererVersion des Reconcilers) neu, verweigert die Ausführung bei abweichenden Paketversionen und gibt mit --dry-run den Plan aus. release:publish baut und packt die Pakete (und löst dabei workspace:* auf), wendet publishConfig an, verweigert die Veröffentlichung einer Vorabversion unter latest oder einer stabilen Version unter canary und überspringt Versionen, die bereits auf npm existieren.
In der Support-Richtlinie erfährst du, wie lange jede Release-Linie gepflegt wird.