muss die versionsnummer nun 2.1.0 oder 2.1.1 heisen?

löscht man also die niederwertigen oder nicht??

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.

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.

wiki weiss alles

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

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.

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

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.

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.

@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.

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.

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

Metafont hat auch ne nette Numerierung

\TeX ist ja auch von nem NERD geschrieben worden

Von Nerds für Nerds

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

...