Zum Hauptinhalt springen

Linear-Vorlage für Veröffentlichungshinweise

Verwende diese Vorlage, wenn du einen Linear-Agenten bittest, Veröffentlichungshinweise für Unraid OS aus einem Release-Projekt, einem Meilenstein oder einer Issue-Liste zu entwerfen.

Eingabeaufforderung für den Linear-Agenten​

Kopiere diese Eingabeaufforderung in Linear und ersetze dann die Werte in Klammern, bevor du sie ausführst.

Draft Unraid OS release notes for [VERSION] using the linked Linear issues, pull requests, package diff, and security notes.

Release context:
- Version: [VERSION]
- Release date: [YYYY-MM-DD]
- Previous release: [PREVIOUS_VERSION]
- Release type: [stable / bugfix / security / beta / release candidate]
- Audience: Unraid OS users upgrading from [PREVIOUS_VERSION]
- Source scope: [Linear project, milestone, label, or issue list]

Output only the final release note Markdown. Do not include process notes, issue IDs, internal-only implementation details, or unsupported claims.

Follow this structure:

# Version [VERSION] [YYYY-MM-DD]

[One short summary paragraph. Mention the most important user-facing themes: security, kernel, Docker, storage, WebGUI, virtualization, licensing, hardware support, API, or package updates.]

[Optional recommendation sentence for security or important bugfix releases.]

## Upgrading

For step-by-step instructions, see [Updating Unraid](/unraid-os/updating-unraid/). Questions about your [license](/unraid-os/troubleshooting/licensing-faq/)?

### Known issues

[List release-specific known issues. If there are no new release-specific known issues, refer to the previous relevant release notes.]

### Notes

[Optional operational notes that are important but not bugs, warnings, or rollback blockers.]

### Rolling back

[List rollback warnings and compatibility limits. Include prior-release links when users need to read earlier rollback notes.]

## BREAKING CHANGES

[Include only when the release changes behavior, configuration, compatibility, data format, upgrade safety, rollback safety, or user workflows in a way users must act on.]

## Changes vs. [PREVIOUS_VERSION_LINK_TEXT]([PREVIOUS_VERSION_LINK])

### Security

- Security: [User-facing security fix, CVE coverage, or hardening change.]

### Containers / Docker

- New: [New Docker or container capability.]
- Improvement: [Improved Docker or container behavior.]
- Fix: [Corrected Docker or container issue.]

### Storage

- New: [New storage capability.]
- Improvement: [Improved storage behavior.]
- Fix: [Corrected storage issue.]

### WebGUI / System

- New: [New WebGUI or system capability.]
- Improvement: [Improved WebGUI or system behavior.]
- Fix: [Corrected WebGUI or system issue.]

### File Manager

- Improvement: [Improved File Manager behavior.]
- Fix: [Corrected File Manager issue.]

### Networking / Hardware

- New: [New networking or hardware support.]
- Improvement: [Improved networking or hardware behavior.]
- Fix: [Corrected networking or hardware issue.]

### Virtualization

- New: [New VM capability.]
- Improvement: [Improved VM behavior.]
- Fix: [Corrected VM issue.]

### Unraid API

- Update Unraid API to dynamix.unraid.net [VERSION] - [see changes](https://github.com/unraid/api/releases).
- Fix: [Corrected API issue.]

### Linux kernel

- Linux kernel: update to `[KERNEL_VERSION]-Unraid`.
- Security: [Kernel CVE coverage, when applicable.]

### Base distro updates

#### Removed packages ([COUNT])

- [package]: version [VERSION] removed

#### Downgraded packages ([COUNT])

- [package]: version [OLD_VERSION] -> [NEW_VERSION]

#### Added packages ([COUNT])

- [package]: version [VERSION]

#### Updated packages ([COUNT])

- [package]: version [OLD_VERSION] -> [NEW_VERSION] [(CVE list, when applicable)]

Entwurfsregeln​

  • Beginnen Sie mit der Nutzerwirkung. Wandeln Sie technische Notizen in das um, was sich für Benutzer, Administratoren oder die Upgradesicherheit geändert hat.
  • Halten Sie Aufzählungspunkte knapp und sachlich. Fügen Sie keine internen Projektnamen, Issue-IDs, Branch-Namen, Commit-Hashes oder Implementierungsdetails hinzu, es sei denn, sie sind für Benutzer relevant.
  • Verwenden Sie die Präfixe New:, Improvement:, Fix: und Security: in Änderungsabschnitten konsequent.
  • Gruppieren Sie zusammengehörige Einträge unter der spezifischsten Überschrift. Verwenden Sie WebGUI / System für allgemeine UI-, Einstellungen-, Systemdienst-, Lizenzstatus- und Benachrichtigungsänderungen.
  • Fügen Sie einen Abschnitt BREAKING CHANGES nur dann ein, wenn Benutzer ihr Verhalten ändern müssen oder wenn sich Rollback-, Kompatibilitäts-, Netzwerk-, Speicher-, Daten- oder Konfigurationsverhalten ändert.
  • Erfinden Sie keine CVEs, betroffenen Pakete, Paketversionen, Rollback-Warnungen, bekannten Probleme oder Upgrade-Empfehlungen. Wenn das Quellmaterial unklar ist, schreiben Sie [NEEDS CONFIRMATION: ...].
  • Behalten Sie öffentliche Quelllinks bei, wenn sie Benutzern helfen, Details zu überprüfen, wie etwa Upstream-Release-Notes, Benutzerberichte oder zugehörige Dokumente.
  • Bevorzugen Sie Docs-Links in diesem Format: /unraid-os/release-notes/[VERSION]/.
  • Verwenden Sie fett für UI-Bezeichnungen und fett kursiv für Navigationspfade, z. B. Einstellungen → Disk-Einstellungen.
  • Verwenden Sie Inline-Code für Paketnamen, Befehle, Konfigurationsschlüssel, Pfade, Versionen, Kernel-Konfigurationssymbole und Fehlermeldungen.
  • Entfernen Sie nicht verwendete optionale Abschnitte vor der Veröffentlichung.

Checkliste für Release Notes​

Vor der Veröffentlichung bestätigen Sie Folgendes:

  • Die Überschrift lautet # Version [VERSION] [YYYY-MM-DD].
  • Die Zusammenfassung erwähnt die wichtigsten Änderungen, ohne jeden Abschnitt zu wiederholen.
  • Hinweise zu Upgrade, bekannten Problemen und Rollback sind für diese Version korrekt.
  • Sicherheitsaussagen stimmen mit bestätigten Advisories oder Paket-Änderungsprotokollen überein.
  • Die Paketanzahlen stimmen mit den Paketlisten überein.
  • Links zur vorherigen Version verweisen auf die richtige Version.
  • Optionale Abschnitte mit Platzhaltern wurden entfernt.