Das Positionspapier ist per Semantic Versioning versioniert. Die öffentliche API des Versionspapiers ist definiert als die Gliederung und die Kerninhalte des Positionspapieres. Eine inkompatible Änderung der API liegt dann vor, wenn

1. die Gliederung insgesamt umstrukturiert wird,
2. eine wesentliche inhaltliche Änderung eines Abschnittes erfolgt oder
3. ein Gliederungspunkt entfernt wird.

Falls ein Unterpunkt hinzugefügt wird, stellt dies nicht notwendigerweise eine inkompatible Änderung der API dar, solange damit keine neue Kernaussage hinzugefügt wird. Umformulierungen von Abschnitten die lediglich dazu dienen den Text klarer und prägnanter zu machen sind auch keine inkompatiblen Änderungen.

Zusammenfassend bildet die Major-Version die Gliederung und die Kernaussagen ab. Die Major-Version muss geändert werden, wenn das Programmpapier neu entwickelt, in Kernaussagen geändert oder mit neuen Ideen wesentlich erweitert wird.

Die Minor-Version wird erhöht wenn die Formulierung verbessert wird oder erläuternde Abschnitt hinzugefügt werden. Dabei ist es auch erlaubt einen ganzen Abschnitt neu zu formulieren ohne den Inhalt wesentlich zu ändern.

Die Patchlevel-Version wird bei minimalen Korrekturen, z.B. der Rechtschreibung oder der Typographie, erhöht. Außerdem wird die Patchlevel-Version erhöht, wenn neue Unterstützer dazukommen.

Im Entwicklungsprozess sind außerdem Pre-Release-Versionen erlaubt. Die verwendeten Stufen sind (N stellt eine aufsteigende natürlich Zahl dar, die Zählung beginnt bei 0):

• alpha.N
• beta.N
• rc.N

Für Patch-Level Releases gibt es keine Pre-Release-Versionen. Die Stufe beta darf übersprungen werden. Das heißt eine mögliche Versionsfolge wäre 1.0.0-rc.0, 1.0.0, 1.0.1, 1.0.2, 1.1.0-alpha.0, 1.1.0-rc.0, 1.1.0.

Die Idee ist, dass man Bestätigungen von Unterstützern nur für Major-Versions neu einholen muss.

Die Quelltexte des Programmpapiers werden auf unserem eigenen git-Server gehostet. Um Zugriff zu erhalten, muss man seinen öffentlichen SSH-Schlüssel an Sebastian, Jonas oder Dominik schicken, und diese können einem dann Zugriffsrechte auf das Repository geben.

Zum clonen verwendet man den Befehl:

git clone git@git.fsfw-dresden.de:positionspapier

Folgender Prozess ist einzuhalten, wenn man eine Version des Programmpapiers (pre-)released:

1. Der (Pre-)Release-Commit sollte lediglich aus der aktuellen PDF-Version des Programmpapiers bestehen.
2. Der (Pre-)Release-Commit sollte ein signiertes Tag der Form v1.0.0-rc.0 tragen (das heißt, die Version mit dem Prefix v) dieses legt man mit dem Befehl git tag -s v1.0.0-rc.0 während der Release-Commit HEAD ist.
3. Bevor man die Änderungen pusht, muss man einen weiteren Commit angelegt haben, in dem die Versionsnummer, die in der Datei positionspapier.version spezifiziert ist, erhöht wurde. Dabei gelten folgende Regeln:
   • auf einen Release folgt das nächste Patch-Level, das heißt 1.0.0 wird zu 1.0.1
   • auf rc.N folgt rc.N+1 (und analog für alpha und beta).
4. Nicht vergessen die Änderungen nun zu pushen.
5. Falls man einen Release durchgeführt hat, muss man die Homepage anpassen. make positionspapier.html erstellt per pandoc eine HTML-Version, die man auf die Website übertragen muss (und die man Korrekturlesen sollte).

1. make
2. pdfbook positionspapier.pdf
3. pdf90 positionspapier-book.pdf