Wie Nummeriert man die Versionen richtig?



  • wenn ich die Version 2.0.0 habe. nun bringe ich eine fehlerkorrektur raus (2.0.1) und nun noch eine leistungserweiterung

    muss die versionsnummer nun 2.1.0 oder 2.1.1 heisen?

    löscht man also die niederwertigen oder nicht??



  • das kannst du machen, wie du willst.
    🙂



  • und wie macht man das normalerweise???



  • So, wie es sich am besten vermarkten lässt. Das wird in der Regel nicht irgendwie logisch gemacht. Mein Chef meint zum Beispiel man könne den Stand eines Projekts damit angeben. 0.40 == 40% fertig 🙄



  • Version schrieb:

    wenn ich die Version 2.0.0 habe. nun bringe ich eine fehlerkorrektur raus (2.0.1) und nun noch eine leistungserweiterung

    muss die versionsnummer nun 2.1.0 oder 2.1.1 heisen?

    löscht man also die niederwertigen oder nicht??

    2.0.0 + Fehlerkorrektur = 2.0.1
    + Leistungerweiterung = 2.1.0
    + Fehlerkorrektur = 2.1.1
    usw.

    Anders sieht es aus, wenn ich 2 Zweige pflegen muss:
    2.0.0 + Leistungerweiterung = 2.1.0
    Dann wollen ein paar die Version 2.0.x weiterverwenden:
    2.0.0 + Fehlerkorrektur = 2.0.1
    2.1.0 + die selbe Fehlerkorrektur = 2.1.1

    Siehe den Linux-Kernel: da wird auch 2.4.x und 2.6.x gepflegt.

    Optimizer schrieb:

    So, wie es sich am besten vermarkten lässt. Das wird in der Regel nicht irgendwie logisch gemacht. Mein Chef meint zum Beispiel man könne den Stand eines Projekts damit angeben. 0.40 == 40% fertig 🙄

    Das ist doch auch richtig? Fuer mich heisst 1.0 wenn der Entwickler alle seine Ziele in der Applikation erreicht hat. 0.x heist, dass zwar etliches ferdig ist, aber halt nicht alles.



  • Optimizer schrieb:

    So, wie es sich am besten vermarkten lässt. Das wird in der Regel nicht irgendwie logisch gemacht. Mein Chef meint zum Beispiel man könne den Stand eines Projekts damit angeben. 0.40 == 40% fertig 🙄

    Ich weiß gar nicht was es da zu "🙄"en gibt.

    Nicht nur dass man sein Versionierungsschema völlig willkürlich gestalten kann, genau so wie es dein Chef vorschlägt wird es sehr oft gehandhabt.





  • Version schrieb:

    nun bringe ich eine fehlerkorrektur raus (2.0.1) und nun noch eine leistungserweiterung
    muss die versionsnummer nun 2.1.0 oder 2.1.1 heisen?

    2.1.0

    denn du springst ja auch bspw. von 2.4 auf 3.0 und nicht gleich auf 3.4



  • finix schrieb:

    Optimizer schrieb:

    So, wie es sich am besten vermarkten lässt. Das wird in der Regel nicht irgendwie logisch gemacht. Mein Chef meint zum Beispiel man könne den Stand eines Projekts damit angeben. 0.40 == 40% fertig 🙄

    Ich weiß gar nicht was es da zu "🙄"en gibt.

    Hast du schon mal an einem großen Software-Projekt gearbeitet? Die Frage "zu wie viel % ist das Projekt fertig?" lässt sich natürlich ganz einfach beantworten...

    Nicht nur dass man sein Versionierungsschema völlig willkürlich gestalten kann, genau so wie es dein Chef vorschlägt wird es sehr oft gehandhabt.

    Ja, so lässt es sich ja auch am besten vermarkten.



  • Optimizer schrieb:

    finix schrieb:

    Optimizer schrieb:

    So, wie es sich am besten vermarkten lässt. Das wird in der Regel nicht irgendwie logisch gemacht. Mein Chef meint zum Beispiel man könne den Stand eines Projekts damit angeben. 0.40 == 40% fertig 🙄

    Ich weiß gar nicht was es da zu "🙄"en gibt.

    Hast du schon mal an einem großen Software-Projekt gearbeitet? Die Frage "zu wie viel % ist das Projekt fertig?" lässt sich natürlich ganz einfach beantworten...

    Die ersten 90% sind fertig. Jetzt kommen die restlichen 90%.

    Doom 1.666 😃



  • Also sowas wie zu 40% fertig machen wir überhaupt nicht. In vielen Projekten waren die Versionsnummern aus dem Bauch heraus oder es wurde einfach hoch gezählt. Das waren immer Anwendungen und keine Libs oder Frameworks. D.h. es waren eher Nummerierungen die für uns intern waren, und wir einfach wussten, wie wir sie benennen. Also vergleichbar einer ID.

    In unserem aktuellen Projekt (ein Framework) machen wir das strikter. Folgende Regeln:

    Vier Stellen für die Versionsnummer getrennt durch Punkte. Bsp.: 2.1.2.RC1

    Erste Stelle ist Main Release: Bedeutende Änderungen und Neuerungen, incl. Schnittstellenänderungen.
    Zweite Stelle ist Minor Release: Neue Funktionen, aber keine Schnittstellenänderungen.
    Dritte Stelle ist Patch Release: nur Fehlerbehebungen.
    Vierte Stelle ist Status Release: z.B. Test, QS oder Final.

    Es wird entsprechend einfach immer hoch gezählt und die zwar an der Stelle, die bedeutender ist. Wenn es also in einem neuen Release neue Funktionen und Fehlerbehebung gibt, wird natürlich nur die Minor-Release-Nummer erhöht und nicht die Patch-Release-Nummer (die wird auf Null zurück gesetzt!).

    Am Ende ist es aber nur eine Regelung von vielen Möglichen. Man kann sich an bestehende Regelungen richten, oder sich selber eine Ausdenken.



  • @Artchi

    Wenn die Minor-Vorsion um eins hochgezaehlt wird, heisst es dann, dass genau 1 weitere Funktion dazugekommen ist, oder ist die Anzahl neuer Funktionen nicht entscheidend? Sprich, zaehlst du die Anzahl der Minor-Version gemaess der Anzahl der neuen Funktionen hoch?

    Das faellt mir naemlich schwer zubeurteilen:
    XYZ v0.7.0
    Es kommt eine Minifunktion dazu:
    XYZ v0.8.0
    Es kommen 20 neue Funktionen hinzu, Schnittstelle aendert sich jedoch nicht:
    XYZ v0.9.0

    Ohne System ist es kacke.



  • Ich frag mich, welche interne Versionsnummer Duke Nukem Forever hat. 😃



  • mir gefällt die versionsnummerierung von ubuntu, so kann man an der versionsnummer erkennen ob man eine neue oder veraltete version benutzt.



  • endline schrieb:

    @Artchi

    Wenn die Minor-Vorsion um eins hochgezaehlt wird, heisst es dann, dass genau 1 weitere Funktion dazugekommen ist, oder ist die Anzahl neuer Funktionen nicht entscheidend? Sprich, zaehlst du die Anzahl der Minor-Version gemaess der Anzahl der neuen Funktionen hoch?

    Das faellt mir naemlich schwer zubeurteilen:
    XYZ v0.7.0
    Es kommt eine Minifunktion dazu:
    XYZ v0.8.0
    Es kommen 20 neue Funktionen hinzu, Schnittstelle aendert sich jedoch nicht:
    XYZ v0.9.0

    Ohne System ist es kacke.

    Das wäre wohl bei neuer Funktionalität sehr unpraktikabel, ständig neue Versionen zu machen. Wir lösen das durch Releasezyklen (alle paar Wochen kommt neue Minor-Version, alle paar Monate neue Version). Einen Patch kann man hingegen auch mal bei nur einem Fehler rausbringen, wenns ein schwerwiegender war.



  • Also die Versionsnummer wird einmal hochgezählt, wenn wir einen Stand im Sourcecode-Repository markieren (Taggen, Releasen oder wie das auch immer im jeweiligen System heißt). Es können natürlich mehrere neue Funktionen enthalten sein und trotzdem wird nur um eins hoch gezählt. Die gesamte Nummer ist ja einfach nur eine ID. Es geht ja darum, das wenn man z.B. Support leistet, der Anrufer sagen kann "Ich habe in Version 1.3.0 einen Fehler entdeckt." oder "Was habt ihr denn in Version 1.5.1 für Bugs behoben?"... Das man dann selber nachschauen kann, was in der Version alles zum Vorgänger bearbeitet wurde. Ohne Versionsnummer wäre man doch aufgeschmissen, die Historie der Entwicklung zu lesen.

    1.5 sagt nicht aus "seit 1.0 gabs 5 neue Funktionen". Nein, es gab einfach 5 gemerkte/markierte Stände im Sourcecode-Repository.

    Bei 1.5.1 weiß ich aber auch, das es eine Fehlerbehebungs-Version war, die anscheinend Fehler aus 1.5.0 behebt. Wieviel Fehler behoben wurden, kann ich nicht aus der Zahl rauslesen. Ich kann das aber im Repository nachschauen! Bzw. der Einfachheit wegen sollte man eine HISTORY.TXT pflegen, und dem zu verteilenden Projektdateien beilegen, dann kann das jeder nachlesen. 😉

    Anderes Szenario: aktuelle Library-Version ist 2.0.0. Aber jemand benutzt noch die Library-Version 1.4.x und kann aus Kostengründen erstmal nicht auf 2.0.0 umsteigen. Findet aber einen schweren Bug in 1.4.1. Ruft an "Habe einen Bug sowieso! Unmöglich vernünftig damit arbeiten zu können!".
    "Also in 2.0.0 ist uns kein Bug sowieso aufgefallen."
    "Habe hier ja auch 1.4.1!"
    "Achso! Ok, werde dann mal aus dem Repository Version 1.4.1 auschecken, Fehler beheben und morgen 1.4.2 bereit stellen."

    Ohne Versionsnummern wäre es unmöglich so einfach zu kommunizieren und so schnell zu handeln. Es ist halt "nur" eine ID.

    Deshalb kann man auch nur empfehlen ein Sourcecode-Management System (SCM) wie Subversion zu benutzen. Gibt aber auch andere SCMs.



  • borg schrieb:

    mir gefällt die versionsnummerierung von ubuntu, so kann man an der versionsnummer erkennen ob man eine neue oder veraltete version benutzt.

    hm deinem namen nach sollte dir die versionsnummerierung von TeX besser gefallen... nähert sich der perfektion 😉



  • \TeX ist ja auch von nem NERD geschrieben worden 😃

    Metafont hat auch ne nette Numerierung



  • darthdespotism schrieb:

    \TeX ist ja auch von nem NERD geschrieben worden 😃

    Von Nerds für Nerds 😃



  • queer_boy schrieb:

    borg schrieb:

    mir gefällt die versionsnummerierung von ubuntu, so kann man an der versionsnummer erkennen ob man eine neue oder veraltete version benutzt.

    hm deinem namen nach sollte dir die versionsnummerierung von TeX besser gefallen... nähert sich der perfektion 😉

    das wusste ich noch gar nicht, aber in der tat, das ist cool 🕶


Log in to reply