Kephra - Gedanken - Versionsnummern

Veröffentlichen Mit Nummern

Von Beginn an wollte ich verständliche Versionsnummern. Das ist aber eine Frage nach den Entwicklungszyklen, denn ihre Nummerierung ist ein ausreichend bekanntes und verstandenes Konzept. Welche Art der Entwicklung paßt zum unserem Ziel und unseren Entwicklern? Der folgende Text legt dar, wie ich auf Antworten zu dieser frage kam. Ich wollte Nummern die nicht nur realistisch den Fortschritt anzeigen, sondern auch Auskunft geben, welcher Art eine Veröffentlichung ist und was ich von ihr erwaten kann.

2 Grundgedanken

Als ich längere Zeit darüber nachdachte und mehrere Möglichkeiten ausprobierte, wurden mir 2 Dinge bewusst.
1. Ein Zahlenstrahl ist eindimensional, er kann also immer nur als Skala einer Sache dienen, ohne ungenau zu werden.
2. Zahlen und ihre Positionen haben wie alle Symbole an sich nur den Sinn der ihnen zugewiesen wird. Hat eine Nachkommastelle immer die gleiche Bedeutung hilft das der Klarheit.

Mein Ideal

Mit anderen Worten: jeder Subzyklus sollte seine eigene getrennte Ziffer bekommen. Ist der Zyklus beendet, kehrt die Zählung zu 0 zurück und der nächsthöhere Zyklus ist einen Zähler weiter, (wie wir das von der Zeitzählung gewohnt sind). Das wäre intuitiv und kommt vollkommen ohne Zusätze wie "RC" und "dev" aus, funktioniert aber nur wenn die Enwicklung selber geradlinig ist und es keine Parallelentwicklungen gibt.

Schemen der Anderen

Innerhalb der freien Softwarewelt gibt es ein Schema, in dem es immer 2 parallele "Schienen" gibt, eine für neue Funktionen und eine die mehr auf Stabilität und Zuverlässigkeit ausgerichtet ist. Erste haben ungerade Ziffern (wie 1.3), letztere ungerade (1.4). Linus fing damit an, doch mitlerweile ging er zu einem Schema über bei dem er in regelmäßigen Zeitabständen einen Zustand als Version einfriert. Dann werden nur noch "bugfixes" akzeptiert und die version klettert 1.6.25-rc1, 1.6.25-rc2 usw bis er entscheided 1.6.24 ist fertig. Diese Version wird dann von Interessierten oder Distributoren weiter gepflegt, deren Fortschritte die vierte Stelle anzeigt (1.6.25.1, 1.6.25.2).

Kephra's Entwicklungsmodell

Das erste Modell kollidiert eindeutig mit dem aufgestellten Ideal, aber auch das zweite ist noch nicht perfekt für Kephra. Es läuft also meist auf den Konflikt Entwicklung kontra Stabilität hinaus. Und da auf Entwicklung schlecht verzichtet werden kann, sollte ich die Frage stellen: Möchte ich eine stabile Version? Selbstverständlich sollten die Benutzer etwas zuverlässiges bekommen. Ich selbst brauche auch etwas, auf das ich immer zurückkommen kann falls, der aktuelle Stand nicht lauffähig ist. Doch mein Ideal ist es auch, das Programm die ganze Zeit so stabil wie möglich zu halten, sodaß es nur wenige Versionen geben muß, um einen als stabil markierten Stand nachträglich zu korrigieren. Der Schwerpunkt liegt also auf Entwicklung und demnach soll unsere Versionierung die Entwicklung wiedergeben. Es bleibt damit die Frage: in welchen Zyklen diese stattfinden soll?

Anzahl der Zyklen

Mich stören zu lange Zahlenkolonnen, aber ich möchte andererseits auch keine extra Revisionszahlen. Deshalb denke ich ein vierstelligen Zahlenschema ist eine gute Balance. Es sieht professionell aus (und ich mein es mit Kephra sehr ernst) und ist auch gerade so noch normal aussprechbar. Und meistens werden eh nur 2 oder 3 Stellen angegeben (0.4 anstatt 0.4.0.0 oder 0.4.1 anstatt 0.4.1.0), da diese Versionen die interessanteren und öffentlicheren sind. Intern kann man ruhig dannden vierstelligen angeben.

Beschreibung der Zyklen

Wie in Abschnitt formuliert sollen die Zyklen 4 sehr verschieden Zielen dienen. Ich denk der erste Zyklus dient der ideelen Ausrichtung von Kephra. Ich möchte mich nicht von Version zu Version hangeln, ohne zu wissen wohin, sondern ich formulierte eine Anfangsvision (die gerne unterwegs geändert werden kann), dieses Ziel ist als 1.0 markiert und die Versionen 0.1, 0.2 .. sind dann die Etappen dahin. Wenn ich den Eindruck habe es ist erreicht, kann ein neues formuliert werden oder eine andere technische Architektur angestrebt werden, die eine neue Nummer bekommt. Die Etappenziele bis 1.0 können nur Benutzerversionen sein. Der zweite Zyklus ist daher auf Stabilität ausgerichtet und eine in sich geschlossene Vollständigkeit der Funktionen die er anbietet. Der Aufwand dafür ist nicht zu unterschätzen und Benutzer werden sich auch nicht jeden Monat etwas neues installieren. Daher werden wir sie ca. alle halbe bis ganze Jahre nur machen (das letzte war nach 3 Jahren vollendet). Nachträglich verbesserte Benutzerversionen werden ein "patchlevel" bekommen, daß nur beim laden und im Infodialog sichtbar sein wird. Da unsere Versionierung die Entwicklung wiedergibt werden z.B. 0.4 und 0.4 PL 3 (idealerweise) funktiongleich sein. Der dritte Zyklus wendet sich nicht an Endbenutzer sondern Tester. Das sind diejenigen freundlichen Leute, die kleinere Schwierigkeiten in Kauf nehmen, um die neuesten Funktionen benutzen zu können und uns die gefundenen Probleme zusenden. Dadurch sind bei der Nutzerversion dann die meisten Probleme schon behoben und wir können so besser die Enwicklung nach aussen vermitteln und mit Interessenten in Kontakt bleiben. Testversionen passieren die Testsuite (außer bei begründeten Ausnahmen) und sind nach bestem Wissen und Gewissen benutzbar, nur können Baustellen sichtbar sein. Im vierte Zyklus sind die Entwickler ganz unter sich. Sie werden mit der Haltung gemacht: "Schau was hältst du davon?". Eine Benutzerversionen garantiert für garnichts und ihre Ziffer zählt in etwa den Fortschritt.