Kann ich einen Rat zur Versionsnummerierung bekommen?

Question

Unser Produkt hat eine lange Geschichte (etwa 12 Jahre).

Seine Ursprünge liegen in VB3 (Version 1) und später in VB6 (Version 2). (Versionsnummern waren ein "Hundefrühstück" und die Versionskontrolle war ein Alptraum.

Ich engagiere mich nun schon seit einigen Jahren hier. Wir haben Version 3 in der Entwicklung auf der .Net-Plattform, aber Version 2 wird weiterhin mit regelmäßigen Veröffentlichungen unterstützt - etwa 3 oder 4 pro Jahr.

Als ich anfing, führte ich nächtliche automatische Builds ein und die Versionsnummer unseres Produkts war 2.2.2. Alle planten, nur 2.2.3 zu veröffentlichen, aber der automatisierte Build-Prozess und das "interessante" dreiteilige Nummerierungssystem von VB6 bedeuteten, dass wir den dritten Teil - die Build-/Revisionsnummer - nutzen mussten, was auch immer das sein sollte.

Also veröffentlichten wir Version 2.3 (mit einer Build-Nummer von "wie auch immer") und arbeiteten an 2.4 (mit nächtlicher Erhöhung der Build-Nummern), dann 2.5, dann 2.6 usw.

Die Build-Nummer war vor der Öffentlichkeit verborgen, aber für Support-Zwecke verfügbar, obwohl wir selten mehr als einen Build einer Version veröffentlichen - wir mussten jedoch gelegentlich patchen.

Konsistenz gewährleistet. Jetzt erreichen wir 2.9. Wir sind auf dem Weg zu 2.10 (Zwei Punkt Neun, bis zu Zwei Punkt Zehn). Leider lesen Nichttechniker dies wie eine rationale Zahl (Zwei - Punkt Eins). Sie können nicht verstehen, warum wir nicht einfach zu Version 3.0 übergehen - wie beim Zählen. (Die Versionsnummer wird nur zu Supportzwecken auf dem Bildschirm "Hilfe/Über" angezeigt).

Ich glaube nicht, dass eine Produktaufwertung (größere Anzahl) gerechtfertigt ist, insbesondere aufgrund der Erwartungen, die dies auf dem Markt wecken wird.

Gibt es einen richtigen Weg, hier vorzugehen? (2.10 oder 3.0 oder etwas Besseres - oder spielt das überhaupt eine Rolle?)

(Anm.: Ich habe mich bemüht, dass die Versionsnummer jetzt als 2.09 statt 2.9 angezeigt wird (auf unserer Website, auf dem Splash-Screen des Produkts und an verschiedenen anderen öffentlichen Stellen usw.), damit es bei der Umstellung auf 2.10 mehr Sinn ergibt, aber das ist möglicherweise genauso verwirrend, weil 2.09 wirklich eine niedrigere rationale Zahl als 2.8 ist...)

Siehe auch:

Entscheidung über die Versionsnummern

Wie kann man Versionsnummern erstellen?

Woher wissen Sie, welche Versionsnummer Sie verwenden müssen?

Answer 1

Betrachten Sie es als eine Chance für die Nicht-Techniker, etwas zu lernen ;-) Versionsnummern sollten wie Kapitel- und Abschnittsnummern in einem Buch sein, sie unterteilen die Lebensdauer Ihres Programms in kohärente und intern konsistente Blöcke.

Answer 2

Die anderen Antworten sind nur halb richtig. Versionsnummern haben die Bedeutung, die Sie ihnen geben, aber sie haben auch die Bedeutung, die andere ihnen geben. Ihre eigene Bedeutung spielt eigentlich keine Rolle, da Sie nicht da sein werden, um Ihre Benutzer zu korrigieren. Wenn sie denken, dass der Wechsel von 2.9 zu 3.0 ein großer Sprung ist, dann werden sie ihn auch so auffassen. Wenn sie Angst davor haben, x.0-Versionen zu verwenden, dann werden sie es nicht tun. Wenn sie daran gewöhnt sind, dass Versionen mit ungeraden Nummern Alphas sind, dann werden sie diese nicht benutzen.

So sehr ich es auch hasse, es zu sagen, Versionsnummern sind ein Marketinginstrument. Sie sagen dem Benutzer etwas über die Veröffentlichung, also müssen Sie das bei der Wahl Ihrer Versionsnummern berücksichtigen.

Das Problem ist, dass die Versionsnummern für verschiedene Menschen unterschiedliche Bedeutungen haben. Es gibt einige Dinge, die man vorhersagen kann. Wie ich bereits erwähnt habe, sind die Leute misstrauisch gegenüber x.0 Versionen. Sie erwarten große Änderungen von 2.x zu 3.x. Wenn Sie versuchen wollen, das zu spielen, nur zu.

Es gibt zwei wesentliche Merkmale von Versionsnummern. Erstens: Sie müssen immer nach oben gehen. Zweitens müssen sie leicht zu sortieren sein. Das erste ist offensichtlich, aber gegen das zweite wird oft verstoßen. Nehmen wir die Version 2.9 -> 2.10. Numerisch gesehen ist 2.9 größer als 2.10. Man muss sie als Haupt-/Nebenversionsnummern betrachten, damit sie richtig sortiert werden können. Daraus ergibt sich die Verwirrung darüber, ob 2.10 oder 3.0 auf 2.9 folgt. Selbst wenn wir die Sortierregeln kennen, scheint das immer noch falsch zu sein. Aus diesem Grund fülle ich meine Versionen immer auf. Auf 2.09 folgt 2.10. Es wird sowohl als Zahl als auch als Punktpaar korrekt sortiert.

Damit bleibt immer noch der Versuch des Benutzers, aus der Versionsnummer eine Bedeutung abzuleiten, wie Numerologen, die Lottozahlen durchgehen. Sie können versuchen, dieses Spiel mitzuspielen, oder Sie können es lassen. Warum überhaupt ein gepunktetes Paar verwenden? Verwenden Sie eine ganze Zahl. Das ist eindeutig. Es sortiert trivial. Es gibt keine falsche Bedeutung, an der sich der Benutzer festhalten könnte.

Ich kann noch einen draufsetzen. Es gibt eine klare Bedeutung, die man einer Versionsnummer geben kann, etwas, das nützlich ist. Es gibt ein Problem, das wir in der CPAN Es gibt viele Leute, die ihre Module nicht aktualisieren, weil sie die Version 1.03 verwenden und die neueste Version 1.07 ist, und siehe da, es ist nur 0,04 Unterschied. Warum sollte man ein Upgrade durchführen? Was nicht gezeigt wird, ist, dass zwischen 1.03 und 1.07 vier Jahre lagen. Microsoft hat das herausgefunden, deshalb kaufen wir Office 2009 und nicht Office 12 (es kann einem auch in den Arsch beißen, wenn man nicht oft neue Versionen herausbringt, wer wollte schon Windows 98 im Jahr 2001?) Es steht direkt in der Versionsnummer. "Widgets 2007" sagt Ihnen, dass Sie sich vielleicht nach einem Upgrade umsehen sollten.

Ich habe früher ISO-Daten als Versionen verwendet. Wenn Sie heute etwas veröffentlichen würden, wäre es Version 20090309. Wenn Sie zwei Versionen an einem Tag veröffentlichen mussten, hängen Sie die Stunde und die Minute an das Ende an: 20090309.2051. Das ist einfach zu sortieren. Es geht immer nach oben. Es vermittelt dem Benutzer eine eindeutige Bedeutung über die Veröffentlichung. Hier ein Beispiel .

Ich verwende jetzt Semantische Versionierung . Sie verwendet eine gepunktete Dreiergruppe, um drei wichtige Informationen zu übermitteln. Wurde die API gebrochen? Wurden neue Funktionen hinzugefügt? Handelt es sich nur um eine Fehlerbehebung? Der Benutzer muss sich bewusst sein, dass Ihr Projekt semantische Versionen verwendet, was ein Nachteil gegenüber ISO-Datumsversionen ist. Der Vorteil ist die Art der Informationen, die sie vermitteln, und dass sie gut definiert sind.

Answer 3

Wie Sie Ihre eigene Software versionieren, bleibt Ihnen überlassen. Es gibt kein "richtig" oder "falsch", sondern nur das, was unter den Gesichtspunkten Wartung, Versionsmanagement und Kundenbetreuung am besten ist. Wichtig ist, dass Sie die Kontrolle über die Versionierung haben - dass Sie sie verstehen, dass jeder, der mit dem Produkt arbeitet, sie versteht, und dass sie später keine Probleme verursacht. Es hat keinen Sinn, von 2.9 zu 2.10 zu gehen, im Gegensatz zu 3.0, außer dem Sinn usted zu geben.

Answer 4

Ich würde vorschlagen, immer mindestens 3 Komponenten in Ihren Versionsnummern zu verwenden und nichts außer der vierten oder weiteren Komponenten zu verstecken. Halten Sie sich überall an diese Konvention, da es für Nicht-Techniker offensichtlich ist, dass es sich nicht um eine rationale Zahl handeln kann, sondern um etwas anderes (d.h. eine Verbindung aus drei ganzen Zahlen).

• 2.8.0
• 2.9.0
• 2.10.0
• 2.11.0
• ...

Außerdem sollten Sie in den Info-Dialogen das Erstellungsdatum (jjjj-mm-tt) neben der Versionsnummer angeben. Wenn der Kunde mit den Versionsnummern verwirrt ist, kann er/sie einfach die Daten vergleichen, d. h. weit für normale Menschen intuitiver ist.

Answer 5

Sie könnten 2.9.1 oder sogar 2.10.1 machen, aber es gibt viele Projekte, die weiter zählen. 2.10, 2.11 12 13 usw.