✔ Versionsnummern von Open Source Projekten

[RedWing]

Hallo,
hat jemand eine Ahnung, wie sich die Versionsnummer eines Open Source Software Projektes
zusammensetzt? Vielleicht auch einen Link zu dem Thema...

Danke und Gruß

RedWing

 

[Christian Fein]

Hallo,
hat jemand eine Ahnung, wie sich die Versionsnummer eines Open Source Software Projektes
zusammensetzt? Vielleicht auch einen Link zu dem Thema...

Danke und Gruß

RedWing

bei jedem Projekt anders

Aber im allgemeinen ist es so das der Versionsprung viel langsamer von statten geht als dies bei Closed Source Programmen der fall ist.
So ist ein Versionsprung von 0.5 - auf 0.8 etwa gleichbedeutend wie unter Closed Source 3.0 auf 4.0.

 

[RedWing]

Hallo Christian,

bei jedem Projekt anders

Heißt das ich kann mir meine Versionsnummer nach Lust und Laune definieren?
Irgendwie schwer zu glauben.
Also ist es egal ob ich nun eine 3 stellige Versionsnummer (0.0.1) hab, oder eine 2
Stellige(0.5), etc...?
Und wenn nicht wo liegen die Unterschiede und was bedeuten die einzelnen Stellen?

Gruß

RedWing

 

[Christian Fein]

Heißt das ich kann mir meine Versionsnummer nach Lust und Laune definieren?
Irgendwie schwer zu glauben.

Natürlich
Falls dir keine Managment Abteilung vorschreibt. Wer sollte besser wissen wann ein
Projekt den Status 1.0 erreicht hat als die Entwickler?

Also ist es egal ob ich nun eine 3 stellige Versionsnummer (0.0.1) hab, oder eine 2
Stellige(0.5), etc...?
Und wenn nicht wo liegen die Unterschiede und was bedeuten die einzelnen Stellen?

Auch das ist nicht wirklich vorgegeben. Aber die erste Zahl nennt sich major Release Nummer. Sollte wirklich nur dann geändert werden wenn dein Projekt ein solch riesen Schritt macht.
Das heisst theoretisch sollte in dem Sprung von 1.0 auf 2.0 genauso viel Entwicklung stecken wie von 0 auf die 1.0.
Die Minor Release Nummer (sprich hinter dem 1. punkt ) entspricht dann der verbesserten Version. Sprich bei einer 1.0 die um wesentliche Funktionen erweitert wurde kannst du hier die 1.1 ansetzen.
Die 3. Minor Release nummer ist meist für bug-fixes oder andere änderrungen. Sprich es wurde nicht wesentliche Features zur software hinzugefügt aber fehler hafter Code ausgetauscht, optimierungen usw durchgeführt.

Wichtig hierbei ist es das die 1.0 wirklich 1.0 bedeuten sollte. Sprich das Projekt existiert schon eine Weile, alle gewollten Features sind implementiert und der Code optimiert.
Das bedeutet unter OpenSource Projekte kann mann auch minor releases ohne weiteres einsetzen. Mann sehe z.b Mozilla Firefox welchen ich seid Version 0.6 eingesetzt habe, und er zu diesem Zeitpunkt schon ein aussergewöhnlicher Browser war. Dennoch ist erst jetzt die 1.0 für ihn passiert.

 

[Thomas Darimont]

Hallo!

Normalerweise sind die Versions Nummern immer wie folgt aufgebaut:
Major.Minor.Patch.

Wobei
Major: Unterschiedliche Major Versionsnummern sind zueinander inkompatibel. -> Z.Bsp. wegen großen Änderungen im zugrundeliegenden API .
Minor: Minor Versionsnummern behalten Quellcode*(1)- und Binärkompatibilität*(2) mit älteren Minor Versionen der selben Major Version.
Patch: Patch gibt die Änderungen/Fehlerbereinigungen der aktuellen Minor Version an.
Auf Patchlevelebene sind alle damit übereinstimmenden Versionen kompatibel (neuere und ältere)

*(1) Qellcodekomaptibel meint, dass sie sich "miteinander" kompilieren lassen.
*(2) Binärkompatibel meint, dass eine Kompilierte Applikation auch mit diesen "binaries" funktioniert.

HTH,
Gruß Tom

 

[RedWing]

Hallo,
damit lässt sich doch was anfangen
Danke für die ausführliche Information von euch beiden...

Gruß

RedWing