richtig versionieren
lima-city → Forum → Programmiersprachen → Sonstige Programmiersprachen
alpha
aussehen
baustelle
beispiel
ermessen
erweiterung
fehler
fertige funktionen
festen schema
final revision
final update
funktion
funktionieren
identifizieren
kompatibel bleiben
meilenstein
nummer
programm
revision
version
-
Hallo, kann mir jemand verraten, wie man beim Entwickeln eines Programms richtig versioniert?
Hab mir folgendes überlegt, aber würde es gerne richtig machen.
a.b.c
a ist eine fertige voll funktionsfähige Version eines Programms (Größere Änderungen z.b Aussehen und Funktionsweise)
b bei Erweiterungen des Programms zb. durch neue voll funktionsfähige Erweiterungen
c bei Erweiterungen, die noch in der Entwicklungsphase sind.
Beispiel:
0.0.0 Leeres Programmgerüst
0.0.1 Neue Funktion wird entwickelt
0.1.0 Neue Funktion ist fertig
0.1.1 Eine neue Funktion wird entwickelt
0.1.2 Eine neue Version der gerade entwickelten Funktion
1.2.0 Zwei fertige Funktionen und ein Programm, das eine Aufgabe erfüllen kann
Ich habe nur keine Idee, wie das aussehen soll, wenn ich parallel an mehreren Baustellen arbeite und mir nicht sicher bin, ob ich eine fertige Funktion später nicht doch erweitere oder ändere. Am einfachsten wäre eine einzelne fortlaufende Zahl, die man bei Änderungen hoch zählt :) -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Du könntest noch hinten eine Build-Nummer anhängen. Das machen viele Unternehmen auch. So kannst du falls du einen Bug findest einfach die Build-Nummer hochschrauben.
Beispiel:
Du lieferst eine vermeintlich fertige Version aus: 1.2.0.
Nun ruft ein Kunde an und meinst du hättest da einen Fehler gemacht. Jetzt beseitigst du den Fehler und schreibst einfach eine Build-Nummer hinten dran: 1.2.0 Build 1 oder so ähnlich. So wären Erweiterungen und Bugfixes an der Build-Nummer ablesbar.
Gruß S.Brosch -
Ich würde die Versionierung nicht aufgund der Funktionen, sondern aufgrund der Meilensteine erstellen. Die Meilensteine hat man natürlich nach Datum/Deadline.
Häufig macht man das also so:
[Hauptversion].[Unterversion].[Revision]
Hauptversion ist hierbei die Version für den Verkauf. Wird ein Programm zB mit komplett neuen Funktionen auf den Markt gebracht, dann ist es die nächste Hauptversion.
Die Unterversion sind die oben genannten Meilensteine. Hier könnte man zB "Alpha", "Beta" oder "RC"-Stadien definieren oder andere großen Meilensteine. zB:
1.0.1: Pre-Alpha, Revision 1 (Grundgerüst)
1.1.1: Alpha 1, Revision 1 (Hauptfunktionen funktionieren teilweise)
1.1.2: Alpha 1, Revision 2 (Haupfunktionen verbessert)
1.2.1: Meilenstein X, Revision 1 (Haupfunktion X implementiert)
1.2.2: Meilenstein X, Revision 2 (Hauptfunktion X Performance verbessert)
1.3.1: Beta1, Revision1 (Alle Hauptfunktionen funktionieren)
1.3.2: Beta1, Revision 2 (Fehler wurden beseitigt)
1.3.3: Beta1, Revision 3 (Weitere Änderungen)
1.4.1: Beta2, Revision 1 (Schönheitsfehler beseitigt)
1.5.1: RC1, Revision 1 (fertige Version, nicht freigegeben)
1.5.2: RC1, Revision 2 (fertige Version, freigegeben)
1.6.0: Final, Revision 1 (fertige Version, veröffentlicht)
1.6.1: Final, Update 1 (Fehler beseitigt)
1.6.2: Final, Update 2 (Fehler beseitigt)
1.8.0: Service-pack 1 (stark überarbeitete Version bzw. viele kleine Updates in einem)
Mal so als Beispiel. Ob ein "Meilenstein" jetzt als "Alpha" oder sonst wie ausgedrückt wird, liegt ganz alleine in deinem Ermessen. Du kannst auch noch ein x.x.x.y hinzufügen, zB für den "Build". -
Ganz ehrlich? Mach' wie du denkst ;)
Versionen dienen in erster Linie dazu, einen bestimmten Codestand eindeutig zu identifizieren. Ob du deine Versionen jetzt "1, 2, 3" oder "Johann, Peter, Walter" nennst, ist dabei völlig egal. In der Realität werden konkrete Versionsnummern sowieso eher aus Marketinggründen vergeben als nach einem festen Schema.
Wie trueweb sagt, ist eine übliche Vorgehensweise [Hauptversion].[Unterversion].[Revision], was auch ganz gut zu deinen Überlegungen passt. Dabei ist mMn nur zu beachten, dass einzelne Hauptversionen immer zueinander kompatibel bleiben sollten. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
