Wie funktionieren frühe Versionsnummern für neue Produkte?

Ich schreibe gerade eine kleine Desktop-Anwendung für einen Freund, aber ich mache sie hauptsächlich als Lernerfahrung für mich. Um mich weiterzubilden und die Dinge richtig zu machen, möchte ich Versionsnummern für diese App haben.

Meine Forschung brachte diese verwandten Ergebnisse hervor

• Welche "Versionsnamenskonvention" verwenden Sie?
• Wie versionieren Sie Ihre Dateien (Versionsnummern)
• Gabeln Sie ein Projekt, wo beginnen meine Versionsnummern?

aber keiner von ihnen befasst sich mit der Nummerierung von Alphas, Betas, Freigabekandidaten usw. Was sind die Konventionen für Versionsnummern unter 1.0? Ich weiß, dass sie noch einige Zeit weitermachen können; Zum Beispiel gibt es PuTTY seit mindestens einem Jahrzehnt und ist immer noch nur in der Beta-Version 0.60.

Es kommt wirklich auf das Projekt an; Einige Projekte veröffentlichen nicht einmal eine Version 1.0.

Die Entwickler von MAME beabsichtigen nicht, eine Version 1.0 ihres Emulatorprogramms zu veröffentlichen. Das Argument ist, dass es niemals wirklich "fertig" sein wird, weil es immer mehr Arcade-Spiele geben wird. Auf Version 0.99 folgte einfach Version 0.100 (Nebenversion 100> 99). In ähnlicher Weise folgte auf Xfire 1.99 1.100. Nach 6 Jahren Entwicklungszeit hat eMule noch nicht einmal die Version 0.50 erreicht. ^{Software-Versionierung bei Wikipedia}

Eine beliebte Methode zur Nummerierung von Versionen (die ich bereits verwendet habe) ist die semantische Versionierung .

Nach diesem Schema vermitteln Versionsnummern und die Art und Weise, wie sie sich ändern, eine Bedeutung für den zugrunde liegenden Code und für die Änderungen, die von einer Version zur nächsten geändert wurden.

Einige Zitate, um Ihnen weitere Ideen zur Funktionsweise zu geben und / oder einige Ihrer Fragen zu beantworten:

Woher weiß ich, wann ich 1.0.0 veröffentlichen muss?

Wenn Ihre Software in der Produktion verwendet wird, sollte sie wahrscheinlich bereits 1.0.0 sein. Wenn Sie eine stabile API haben, von der Benutzer abhängig sind, sollten Sie 1.0.0 sein. Wenn Sie sich große Sorgen um die Abwärtskompatibilität machen, sollten Sie wahrscheinlich bereits 1.0.0 sein.

Entmutigt dies nicht eine schnelle Entwicklung und eine schnelle Iteration?

In der Hauptversion Null dreht sich alles um die schnelle Entwicklung. Wenn Sie die API jeden Tag ändern, sollten Sie sich entweder noch in Version 0.xx oder in einem separaten Entwicklungszweig befinden, der an der nächsten Hauptversion arbeitet.

Wenn selbst die kleinsten rückwärts inkompatiblen Änderungen an der öffentlichen API einen größeren Versionsschub erfordern, werde ich dann nicht sehr schnell bei Version 42.0.0 landen?

Dies ist eine Frage der verantwortungsvollen Entwicklung und Voraussicht. Inkompatible Änderungen sollten nicht leichtfertig in Software eingeführt werden, die viel abhängigen Code enthält. Die Kosten, die für ein Upgrade anfallen müssen, können erheblich sein. Wenn Sie größere Versionen anstoßen müssen, um inkompatible Änderungen freizugeben, müssen Sie die Auswirkungen Ihrer Änderungen durchdenken und das Kosten-Nutzen-Verhältnis bewerten.

Es gibt auch Regeln zum Festlegen von "Alpha" -, "Beta" usw.-Versionen. Überprüfen Sie die Details unter http://semver.org/ .

[Bearbeiten] Ein weiteres interessantes Versionsnummerierungsschema ist das von MongoDB verwendete :

MongoDB verwendet die ungeraden Versionen für Entwicklungsversionen.

In einer MongoDB-Version gibt es 3 Nummern: ABC

• A ist die Hauptversion. Dies wird sich selten ändern und sehr große Änderungen bedeuten
• B ist die Versionsnummer. Dies beinhaltet viele Änderungen, einschließlich Funktionen und Dinge, die möglicherweise die Abwärtskompatibilität beeinträchtigen. Gerade Bs werden stabile Zweige sein, und ungerade Bs werden sich entwickeln.
• C ist die Versionsnummer und wird für Fehler und Sicherheitsprobleme verwendet.

Beispielsweise:

• 1.0.0: erste GA-Version
• 1.0.x: Fehlerbehebungen auf 1.0.x - dringend zu aktualisieren, sehr geringes Risiko
• 1.1.x: Entwicklungsversion. Dies schließt neue Funktionen ein, die noch nicht vollständig fertiggestellt sind und in Arbeit sind. Einige Dinge können sich von 1.0 unterscheiden
• 1.2.x: zweite GA-Version. Dies wird der Höhepunkt der Version 1.1.x sein.

Ich glaube nicht, dass es einen "Standard" als solchen gibt.

Es gibt eine Konvention für Release Candidates, die normalerweise "[version] RC 1" usw. lautet, je nachdem, wie viele Versionen Sie möglicherweise veröffentlichen.

Wenn Sie eine sehr frühe Version Ihres Produkts veröffentlichen - eine, deren Funktion nicht vollständig ist -, sollten Sie die Version "0" verwenden. Auf diese Weise können Sie die Version im Laufe der Zeit erhöhen, während Sie Ihren Funktionsumfang ausfüllen.

Ich würde "Alpha" und "Beta" wie Release Candidate verwenden - für zeitlich begrenzte Versionen, um anzuzeigen, dass Sie der Meinung sind, dass Sie kurz vor der Veröffentlichung der Vollversion stehen.

Es gibt eine Wikipedia-Seite zur Software-Versionierung . Für die Freigabe von Versionen vor 1.0 funktioniert die von Apple und anderen verwendete Konvention gut: major.minor.maintSrev wobei S der Stufenindikator für Vorabversionen ist: d = Entwicklung, a = Alpha, b = Beta, rc = Release Candidate. Ihre erste interne Version könnte also 1.0.0d1 sein.

Für vollständig interne Revisionen ist der Zeitstempel ausreichend.

Jeder Entwickler entscheidet größtenteils, welchen Standard er verwenden wird. Im Allgemeinen weisen Zahlen links vom Dezimalpunkt jedoch auf große Überarbeitungen hin, die für den durchschnittlichen Benutzer wahrscheinlich sehr auffällig wären (z. B. Änderungen der Funktionalität oder der Benutzeroberfläche usw.). Auf der rechten Seite des Dezimalpunkts wäre dies eine Änderung / Modifikation / Hinzufügung, die die Gesamtfunktionalität und das Design nicht wesentlich verändert, aber etwas am Programm selbst geändert hat (dh eine Funktion schneller machen, während immer noch dasselbe getan oder behoben wird ein Sicherheitsproblem). Wenn Sie dann zusätzliche Dezimalstellen hinzufügen, weisen die Zahlen rechts davon auf immer kleinere Änderungen hin (dh kleinere Fehlerbehebungen / Sicherheitsprobleme und dergleichen).

Wie andere gesagt haben, scheint es keinen genauen Standard zu geben. Unsere Organisation verwendet die folgende Notation:

Release 1.0 ---> 2.0 (Eine wichtige neue / verbesserte Funktion, die dem Produkt hinzugefügt wurde)

Release 1.0 ---> 1.1 (Eine neue / verbesserte Funktion auf mittlerer Ebene, die dem Produkt hinzugefügt wurde)

Release 1.0 ---> 1.001 (Bugfixes)

Der „Version 1.0“ Meilenstein ist sehr wichtig für erfahrene Computer - Nutzer, da es bedeutet , dass das Programm fertig und funktioniert wie erwartet. Alles in Version "0.something" impliziert, dass die Programmierer selbst denken, dass das Programm noch nicht fertig ist.

Sie können die Versionsnummern "0.1", "0.2" ... für wichtige Funktionen beibehalten und sie dann mit einer Build-Nummer unterteilen, bei der es sich häufig um ein ausreichend feinkörniges Datum und einen Zeitstempel handelt.