Richtlinien für die Versionierung

==== Einfache Versionierung

[%header]
|===
|Upstream-Version | Version-Tag | Erklärung

|1.0     |1.0         | Das erste Release.

|1.1     |1.1         | Eine Upstream-Aktualisierung.

|1.2.1   |1.2.1       | Eine weitere Upstream-Aktualisierung. Zusätzliche Versionierungsebenen sind OK…

|1.3     |1.3         | …sie können problemlos kommen und gehen.
|===

In diesem Fall könnte die vollständige N-V-R beispielsweise `pkg-1.2.1-1.fc{AKTUELLEVERSION}` (unmittelbar nach einer Aktualisierung) oder `pkg-1.2.1-5.fc{AKTUELLEVERSION}` (nach Downstream-Rebuilds mit derselben Upstream-Version) lauten.

[%header]
|===
|Upstream-Version | Version-Tag | Erklärung

| 5.2    | 5.2        | Upstream-Release.

| 5.2a   | 5.2a       | Die Entwickler haben einen Buchstaben eingeführt, um Patch-Releases zu kennzeichnen. Da Sie darauf vertrauen, dass die Entwickler die Buchstaben in alphabetischer Reihenfolge verwenden, können Sie die Versionsangabe unverändert übernehmen.

| 5.2b   | 5.2b       | Weiteres Patch-Release nach 5.2 — keine Beta.

| 5.2b.1 | 5.2b.1     | Auch das ist OK, solange die Sequenz erhöht wird.

| 5.3    | 5.3        | Weiteres Upstream-Release.
|===

In diesem Fall könnte die vollständige N-V-R beispielsweise so aussehen: `pkg-5.2b.1-1.fc{AKTUELLEVERSION}`.

==== Komplexe Versionierung bei möglicher Zusammenarbeit mit Upstream-Entwicklern

[%header]
|===
|Upstream-Version | Version-Tag | Erklärung

| 1.0.0-rc1 | `+1.0.0~rc1+` | erste Vorveröffentlichung

| 1.0.0-rc2 | `+1.0.0~rc2+` | zweite Vorveröffentlichung

| 1.0.0     | `+1.0.0+`     | Release

| 1.0.1     | `+1.0.1+`     | Bugfix-Release

| 1.0.1-security1 | `+pkg-1.0.1.security1+` | sicherheitsrelevantes Bugfix-Release
|===

In diesem Fall könnte die vollständige N-V-R beispielsweise `pkg-1.0.0~rc2-42.fc{AKTUELLEVERSION}` lauten (wenn viele Rebuilds durchgeführt wurden).

==== Komplexe Versionierung mit nicht-sortierenden Upstream-Nachveröffentlichungsversionen

[%header]
|===
|Upstream-Version | Version-Tag | Erklärung

| 1.1.0~BETA      | `+1.1.0~BETA+` | Vorveröffentlichung, erste Beta

| 1.1.0~BETA1     | `+1.1.0~BETA1+` | Vorveröffentlichung, zweite Beta

| 1.1.0~BETA2     | `+1.1.0~BETA2+` | Vorveröffentlichung, dritte Beta

| 1.1.0~CR1       | `+1.1.0~CR1+` | Vorveröffentlichung, Release-Kandidat 1

| 1.1.0~CR2       | `+1.1.0~CR2+` | Vorveröffentlichung, Release-Kandidat 2

| 1.1.0-1%        | `+1.1.0+` | finales Release

| 1.1.0-GA1       | `+1.1.0.20201001.GA1+` | Nachveröffentlichung, GA1

| 1.1.0-CP1       | `+1.1.0.20201011.CP1+` | Nachveröffentlichung, CP1, nach GA1, wird nicht sauber sortiert

| 1.1.0-CP2       | `+1.1.0.20201101.CP2+` | Nachveröffentlichung, CP2, nach CP1

| 1.1.0-SP1       | `+1.1.0.20210101.SP1+` | Nachveröffentlichung, SP1, nach CP2

| 1.1.0-SP1-CP1   | `+1.1.0.20210105.SP1_CP1+` | Nachveröffentlichung, SP1_CP1, nach SP1
|===

In diesem Fall könnte die vollständige N-V-R beispielsweise so aussehen: `pkg-1.1.0.20210105.SP1_CP1-1.fc{AKTUELLEVERSION}`.

==== Komplexe Versionierung mit Vorabversion- und Nachveröffentlichungs-Snapshots

[%header]
|===
|Upstream-Version | Version | Erklärung

| 1.0.0-rc1            | `+1.0.0~rc1+` | Erste Vorveröffentlichung

| 1.0.0-rc2            | `+1.0.0~rc2+` | Zweite Vorveröffentlichung

| git commit `f00fabd` | `+1.0.0~rc2^20210101gf00fabd+` | Snapshot *nach* der Vorveröffentlichung

| 1.0.0                | `+1.0.0+`     | Ein Release

| 1.0.1                | `+1.0.1+`     | Ein Bugfix-Release

| git commit `bbbccc0` | `+1.0.1^20210203gbbbccc0+` or `+pkg-1.0.1^1.gbbbccc0+` | Ein Snapshot

| 1.0.1-security1      | `+1.0.1.security1+` | Eine Sicherheitsaktualisierung. Erfahrungsgemäß verfügen diese Aktualisierungen über sortierbare Versionsnummern. Falls nicht, könnte man stattdessen '`+<Datum>.security1+`' verwenden.

| git commit `abc0202` | `+1.0.1.security1^20210301gabc0202+` or `+pkg-1.0.1.security1^1.gabc0202+` | Ein weiterer Snapshot
|===

In diesem Fall könnte die vollständige N-V-R beispielsweise so aussehen: `pkg-1.0.1.security1^20210301gabc0202-1.fc{AKTUELLEVERSION}`.

[#traditional-versioning]
== Traditionelle Versionierung mit einem Teil der Upstream-Versionsinformationen im Release-Feld

Die in diesem Abschnitt beschriebene Methode wird als veraltet angesehen, **kann aber noch verwendet werden**. Wie bereits im Abschnitt xref:_handling_non_sorting_versions_with_tilde_dot_and_caret [Umgang mit nicht sortierbaren Versionen mithilfe von Tilde, Punkt und Caret] erwähnt, wird diese Methode für Pakete mit komplexer Versionsverwaltung empfohlen, insbesondere für die Unterstützung von RHEL7 und anderen Systemen mit älteren RPM-Versionen.

Bei dieser Methode wird `+%autorelease+` nicht verwendet, und das Feld `Release` muss manuell verwaltet werden.

Diese Methode zur Behandlung der meisten Vor- und Nachveröffentlichungsversionen sowie nicht sortierbarer Versionen beinhaltet das mögliche Entfernen einiger Informationen aus dem `+Version:+`-Tag und das Hinzufügen einer zusätzlichen Struktur zum `+Release:+`-Tag. Der strukturierte `+Release:+`-Tag kann potenziell aus vier Feldern bestehen:

* Release-Nummer des Pakets (`+<pkgrel>+`)
* Zusätzliche Versionsinformationen (`+<extraver>+`)
* Snapshot-Information (`+<snapinfo>+`)
* minimale Erhöhung der Versionsnummer (`+<minorbump>+`)

Die Release-Nummer des Pakets **muss** immer angegeben werden, während die anderen Angaben je nach Situation vorhanden sein können oder nicht.

Die vorhandenen Elemente werden (durch Punkte getrennt) zum endgültigen `+Release:+`-Tag kombiniert. In der üblichen Notation, wobei eckige Klammern optionale Elemente kennzeichnen:

    <pkgrel>[.<extraver>][.<snapinfo>]%{?dist}[.<minorbump>]

Die tatsächlichen Werte für diese drei Felder hängen von der jeweiligen Situation ab und werden in den folgenden Abschnitten erläutert. Beachten Sie, dass in Ihrem speziellen Fall `+<extraver>+` oder `+<snapinfo>+` möglicherweise nicht benötigt werden und `+<minorbump>+` in den meisten Fällen überhaupt nicht verwendet wird. Lassen Sie einfach die Felder weg, die Sie nicht benötigen.

Beachten Sie, dass das „dist“-Tag von anderen Systemkomponenten bereitgestellt wird und unter Umständen zusätzliche Strukturen, einschließlich Tilden, enthalten kann. Da dies nicht im Einflussbereich des Paketierers liegt, wird diese Struktur hier nicht behandelt. Der Paketierer **muss** `+%{?dist}+` unverändert wie oben angegeben einfügen.

=== Nicht sortierbare Versionen

Wenn das Upstream-Projekt ein Versionsschema verwendet, das nicht korrekt sortiert, prüfen Sie zunächst, ob sich Teile der Versionszeichenkette rechts entfernen lassen, so dass der Rest sortierbar ist. Dies ist oft möglich, wenn die Upstream-Version eine Sequenz wie („1.2pre1“, „1.2pre2“, „1.2final“) verwendet. Verwenden Sie in diesem Fall den entfernten Teil als `+<extraver>+` (siehe oben) und den Rest als Paketversion. Falls durch diese Aufteilung ein führender oder nachfolgender Punkt entsteht, entfernen Sie diesen.

Falls dies nicht möglich ist, verwenden Sie „Version: 0“ und verschieben Sie die _gesamte_ Versionszeichenkette in `+<extraver>+`.

=== Snapshots

Alle Snapshots **müssen** ein Snapshot-Informationsfeld (`+<snapinfo>:+`) im `+Release:+`-Tag enthalten. Dieses Feld muss mindestens das Datum im achtstelligen Format „JJJJMMTT“ enthalten. Der Paketierer **kann** nach dem Datum bis zu 17 Zeichen zusätzlicher Informationen hinzufügen. Folgende Formate werden empfohlen:

* `+JJJJMMTT.<Revision>+`
* `+JJJJMMTT<SCM><Revision>+`

Dabei ist `+<SCM>+` eine kurze Zeichenkette, die das vom Upstream-Projekt verwendete Versionsverwaltungssystem identifiziert (z. B. „git“, „svn“, „hg“) oder die Zeichenkette „snap“. Die `+<Revision>+` ist entweder ein kurzer Git-Commit-Hash, eine Subversion-Revisionsnummer oder etwas anderes, das die genaue Revision im Versionsverwaltungssystem des Upstream-Projekts identifiziert. Wird CVS verwendet, existieren solche Revisionsinformationen natürlich nicht, daher werden sie weggelassen; andernfalls **sollten** sie angegeben werden.

=== Vorabversionen

Verwenden Sie im `+Version:+`-Tag die Versionsnummer, die die Upstream-Entwickler für die nächste Veröffentlichung festgelegt haben. Verwenden Sie für das Feld des `+Release:+`-Tags eine Zahl der Form „0.N“, wobei N eine ganze Zahl ist, die mit 1 beginnt und für jede Revision des Pakets erhöht wird. Vorabversionen **müssen** ein `+Release:+`-Tag kleiner als 1 verwenden, da dies der einzige Hinweis darauf ist, dass eine Vorabversion paketiert wurde.

=== Release- und Post-Release-(Nachveröffentlichungs-)versionen

Verwenden Sie für das Feld `+<pkgrel>+` des Tags `+Release:+` eine ganze Zahl, die mit 1 beginnt und für jede Revision des Pakets erhöht wird. Release- und Post-Release-Versionen **müssen** für das `+Release:+`-Tag eine Zahl größer oder gleich 1 verwenden.

=== Rebuilds in älteren Zweigen mittels `<minorbump>`

In der unter <<Only an old branch needs a change>> beschriebenen Situation **können** Sie `+Release+` anpassen, indem Sie eine Zahl *nach* dem dist-Tag anhängen. Dadurch erstellen Sie eine E-V-R für F{AKTUELLEVERSION}, die immer noch niedriger ist als die in F{NÄCHSTEVERSION}. Setzen Sie `+<minorbump>+` auf eine ganze Zahl, die mit „1“ beginnt, und erhöhen Sie sie für jede kleinere Aktualisierung um 1. Entfernen Sie `+<minorbump>+`, sobald Sie die Paketversion normal erhöhen können, ohne Probleme mit der Reihenfolge zu verursachen.

=== Beispiele

Viele mögliche Szenarien der traditionellen Versionierung finden Sie in den https://fedoraproject.org/wiki/Package_Versioning_Examples[Beispielen zur Paketversionierung].


== Rawhide darf vorübergehend „zurückbleiben“

Ein Paket **kann** vorübergehend einen niedrigeren EVR-Wert in Rawhide im Vergleich zu einem Release-Zweig von Fedora haben, jedoch nur dann, wenn das Paket in Rawhide nicht gebaut werden kann. Dies ermöglicht es, wichtige Aktualisierungen unabhängig vom aktuellen Status von Rawhide in bestehende Fedora-Releases zu integrieren.