✔ Versionsnummern von Open Source Projekten
- Themenstarter RedWing
- Beginndatum
Christian Fein
Erfahrenes Mitglied
RedWing hat gesagt.:
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
Erfahrenes Mitglied
Hallo Christian,
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
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
Erfahrenes Mitglied
RedWing hat gesagt.:
Natürlich
Falls dir keine Managment Abteilung vorschreibt. Wer sollte besser wissen wann ein
Projekt den Status 1.0 erreicht hat als die Entwickler?
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
Erfahrenes Mitglied
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
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
