Frage Was ist als Erstversion zu verwenden?


Normalerweise starte ich meine Projekte mit einer Version 1.0.0. Sobald ich ein paar Sachen zusammen habe, lasse ich es als 1.0.0 los und mache weiter mit 1.1.0.

Allerdings führt dies zu brauchbaren, aber nicht genau vollständigen Version 1.0.0 der meisten Sachen, die ich schreibe. Ich füge dann Features hinzu und komme zu einer anständigen Version irgendwo um 1.6.0. Viele Projekte beginnen mit der Version 0.1.0, die so gut funktioniert wie meine 1.0.0.

Was würdest du vorschlagen? Beginnen Sie mit 1.0.0 oder 0.1.0?

Die letzte Nummer ist übrigens nur für Bugfix-Releases. Sie können sich 1.0.0 als 1.0 und 0.1.0 als 0.1 vorstellen, das ist einfacher für Sie.


75
2017-09-16 16:22


Ursprung


Antworten:


Meine Versionierung wird vom Setup gesteuert. Ich möchte, dass es ältere Versionen ersetzt, also vergrößere ich es in Sprüngen, die für mich Sinn ergeben.

Manchmal wird die Versionierung jedoch vom Kunden gesteuert, insbesondere wenn Sie den Code für die Öffentlichkeit freigeben.

Wenn es Ihr Anruf ist, tun Sie, was für Sie am besten funktioniert. Ich hatte einige Probleme mit Versionen vor 1.0, also fange ich damit an.


-8



Das Semantische Versionierung 2.0.0 Standard sagt:

Das einfachste, was zu tun ist, starten Sie Ihre erste Entwicklungsversion bei   0.1.0 und erhöhen Sie dann die Nebenversion für jede nachfolgende Version.

Es ist in Ordnung, von 0.3.0 direkt auf 1.0.0 zu wechseln. Es ist auch vollkommen in Ordnung, bei 0,23.0 zu sein. Ab 0.4.0 zu starten ist etwas unpassend, da es darauf hindeutet, dass es zuvor veröffentlichte Versionen gab.

Beachten Sie außerdem, dass 0.y.z wird für schnelle Iteration beiseite gelegt, so dass die anfängliche Entwicklung (und daher viele brechende Änderungen) Sie nicht auf etwas dummes wie 142.6.0 verlassen. Anstatt die Hauptversion zu stoßen, bumpe die Nebenversion bei jeder brechenden Änderung, bis du 1.0.0 veröffentlichst:

Hauptversion Null (0.y.z) ist für die anfängliche Entwicklung. Alles kann sich jederzeit ändern. Die öffentliche API sollte nicht als stabil betrachtet werden.


124



Wenn ich meine erste benutzbare Version bekomme, aber keine komplette Version, versuche ich normalerweise zu beurteilen, wie weit es in Richtung einer Feature Complete Version ist. Wenn also zum Beispiel 33% Feature komplett ist, mache ich die Versionsnummer 0.3.0 oder ähnlich. Wenn ich dann in Richtung Feature gehe, werden entsprechende Versionen in ähnlicher Weise mit Zahlen versehen.

Sobald Sie jedoch an einem Feature vorbeigegangen sind, muss sich die komplette Versionierung ändern


1



Ich denke, hier spielen verschiedene Faktoren eine Rolle. Psychologische / Marketing-Auswirkungen der Versionsnummer (häufig erhöhte Versionsnummer => mehr $$$, die Leute wollen keine 0,99 Beta-Version kaufen, etc.) müssen berücksichtigt werden. "Logic" -Versionen können bei der Arbeit in einem großen Team helfen.

Und ich mag den Linux-Weg, ungerade Zahlen für die instabilen Versionen und sogar Zahlen für den stabilen zu haben.


1



Die Versionsnummer liegt ganz bei Ihnen. Machen Sie, was sinnvoll ist Sie und sei konsequent. Niemand sagt, dass Sie von 0 oder 0.0 oder 1.0 oder 1.1 ausgehen müssen.

Große Programmierer haben das Versionsnummerierungssystem tatsächlich als lokale Witze benutzt. Beispiele (Wikipedia):

Seit Version 3 verwendet TeX ein   idiosynkratische Versionsnummerierung   System, wo Updates waren   angezeigt durch Hinzufügen einer zusätzlichen Ziffer bei   das Ende der Dezimalzahl, so dass die   Versionsnummer asymptotisch   nähert sich π. Dies ist eine Reflektion von   die Tatsache, dass TeX jetzt sehr stabil ist,   und nur kleinere Updates sind   erwartet. Die aktuelle Version von   TeX ist 3.1415926; es wurde zuletzt aktualisiert   im März 2008

Für METAFONT:

Metafont hat ein Versionierungssystem   ähnlich wie bei TeX, wo die   asymptotisch nähert sich die Zahl e   mit jeder Überarbeitung.

Schließlich ist die Versionsnummer, aber ebenso interessant, dass Googles Börsengang bei der SEC eingereicht wurde, um $ 2.718.281.828 zu sammeln (Anmerkung: ~ 2.718 281 828).

Mein Punkt ist: Fühle nicht, dass du der Menge folgen musst. Sei kreativ und konsequent.


1



In der Regel hat die Versionierung für den Programmierer eine gewisse Bedeutung. Das Erhöhen der Major-Nummer kann auf große Änderungen hinweisen, die eine Abwärtskompatibilität verhindern. Andere Nummern in der Versionsnummer können auf kleinere Feature-Verbesserungen oder Fehlerbehebungen hinweisen.

Wenn Sie sich Sorgen machen, dass Version 0.6.5 einen unvollständigen Klingelton hat, möchten Sie es vielleicht unter Version 1.0 vermarkten. Ihre Marketingversionsnummer muss nicht mit Ihrer internen Versionsnummer übereinstimmen. Die Versionsnummer von Windows 7 lautet beispielsweise 6.1.

Meine persönliche Vorliebe ist von 0.1.0 zu starten und von dort zu gehen.


0



Bei der Auswahl der Versionsnummern für ein npm Paket, beachten Sie, dass für Abhängigkeiten in aufgeführt package.json  sherver Bereiche funktioniert nicht unter v1.0.0. Das ist,

"dependencies": {
    "my-package": "^0.5"
}

ist äquivalent zu

"dependencies": {
    "my-package": "0.5"
}

Wenn Sie in der Lage sein möchten, semver-Bereiche zu verwenden, oder Sie andere Personen verwenden lassen möchten, sollten Sie mit 1.0.0 beginnen


0



Hängt vom Projekt ab. Für einfache Kommandozeilen-Tools starte ich normalerweise bei 0.9 [.0], da ich nur in Erwägung ziehe, sie zu veröffentlichen oder zu packen, wenn sie kurz vor dem Abschluss stehen (oder bereit für den Betatest). Kompliziertere Projekte beginnen bei 0.1 [.0] und manche sehen nie 1.0. Ich betrachte 1.0 als Release-Version (oder zumindest als lokal getesteten Beta oder Release-Kandidat) und plane entsprechend.

Bei Team-Projekten entscheidet sich wer das erste Version-Tag setzt :).


-1



Die Versionsnummern sollten für Sie als wichtig sein Arrieta richtig vorher kommentiert.

Vielleicht folgt etwas wie: First # ist Bürgermeister Release, Second # ist die gleiche Bürgermeister Release mit einigen Funktionen hinzugefügt und Third # ist die gleiche Bürgermeister Release, mit den gleichen Funktionen, aber mit behobenen Bugs oder hinzugefügt wenig (aber signifikant genug) Änderungen.

1.3.2 => 1. Release, mit mehr Funktionen und einigen Bugs behoben.

Für die Endbenutzer sind einige jedoch an große Zahlen für die endgültigen Veröffentlichungen gewöhnt.

Zum Beispiel: Corel 8, für 8.0.0, 8.0.1, 8.2.2 usw. Corel 9, für 9.0.0 ... usw.

Und meistens geht es um Marketingstrategien wie: Corel X5 statt Corel 15.0.2 zum Beispiel.

Ich würde sagen, dass es darauf ankommt, ob die Versionsnummer für Sie oder für den Kunden ist.


-2