Best Practice: Softwareversionierung [geschlossen]

Gibt es eine Richtlinie oder eine bewährte Standardmethode für die Versionierung einer Software, die Sie in Ihrer Freizeit zum Spaß entwickeln, die jedoch von einigen Personen verwendet wird? Ich denke, es ist notwendig, eine solche Software zu versionieren, damit Sie wissen, mit welcher Version man spricht (z. B. zur Fehlerbehebung, Unterstützung usw.).

Aber wo fange ich mit der Versionierung an? 0,0,0? oder 0,0? Und wie erhöhe ich dann die Zahlen? Hauptversion. Kleinere Änderung? und sollte kein Commit für ein Versionskontrollsystem eine andere Version sein? oder ist dies nur für produktionen, die produktiv eingesetzt werden?

Sie sollten mit Version 1 beginnen, es sei denn, Sie wissen, dass die erste Version, die Sie "veröffentlichen", in irgendeiner Weise unvollständig ist.

Wie Sie die Versionen erhöhen, liegt ganz bei Ihnen. Verwenden Sie jedoch die Haupt-, Neben- und Build-Nummerierung als Richtlinie.

Es ist nicht erforderlich, jede Version, die Sie zur Quellcodeverwaltung verpflichten, als eine andere Version zu haben - Sie werden in der Tat bald eine sehr große Versionsnummer haben. Sie müssen die Versionsnummer nur (in gewisser Weise) erhöhen, wenn Sie eine neue Version für die Außenwelt freigeben.

Wenn Sie also eine größere Änderung vornehmen, wechseln Sie von Version 1.0.0.0 zu Version 2.0.0.0 (Sie haben beispielsweise von WinForms zu WPF gewechselt). Wenn Sie eine kleinere Änderung vornehmen, wechseln Sie von 1.0.0.0 zu 1.1.0.0 (Sie haben Unterstützung für PNG-Dateien hinzugefügt). Wenn Sie eine geringfügige Änderung vornehmen, wechseln Sie von 1.0.0.0 zu 1.0.1.0 (Sie haben einige Fehler behoben).

Wenn Sie wirklich detailliert werden möchten, verwenden Sie die endgültige Nummer als Build-Nummer, die bei jedem Einchecken / Festschreiben erhöht wird (aber ich denke, das geht zu weit).

Ich würde eine x.y.zArt Versionierung verwenden

x- Hauptversion
y- Nebenversion
z- Build-Nummer

Ich folge grundsätzlich diesem Muster:

• ab 0.1.0

• Wenn es fertig ist, verzweige ich den Code im Quell-Repo, tagge 0.1.0 und erstelle den 0.1.0-Zweig. Der Kopf / Stamm wird zu einem 0.2.0-Snapshot oder ähnlichem

• Ich füge nur dem Trunk neue Funktionen hinzu, aber Backport-Korrekturen am Zweig und mit der Zeit löse ich 0.1.1, 0.1.2, ...

• Ich erkläre Version 1.0.0, wenn das Produkt als vollständig angesehen wird und keine größeren Mängel aufweist

• Von da an kann jeder entscheiden, wann die Hauptversion erhöht werden soll ...

Ich verwende diese Regel für meine Anwendungen:

xyz

Wo:

• x = Hauptversionsnummer, 1- ~.
• y = Merkmalsnummer, 0-9. Erhöhen Sie diese Zahl, wenn die Änderung neue Funktionen mit oder ohne Fehlerkorrekturen enthält.
• z = Hotfixnummer, 0- ~. Erhöhen Sie diese Zahl, wenn die Änderung nur Fehlerbehebungen enthält.

Beispiel:

• Bei neuen Anwendungen beginnt die Versionsnummer mit 1.0.0.
• Wenn die neue Version nur Fehlerbehebungen enthält, erhöhen Sie die Hotfix-Nummer, sodass die Versionsnummer 1.0.1 lautet.
• Wenn die neue Version neue Funktionen mit oder ohne Fehlerkorrekturen enthält, erhöhen Sie die Funktionsnummer und setzen Sie die Hotfix-Nummer auf Null zurück, sodass die Versionsnummer 1.1.0 lautet. Wenn die Funktionsnummer 9 erreicht, erhöhen Sie die Hauptversionsnummer und setzen Sie die Funktions- und Hotfixnummer auf Null zurück (2.0.0 usw.)

Wir verwenden abcd wo

• a - major (erhöht bei Lieferung an den Kunden)
• b - minderjährig (erhöht bei Lieferung an den Kunden)
• c - Revision (inkrementiert bei internen Releases)
• d - Build (erhöht durch Tempomat)

Ein weiteres Beispiel für diesen A.B.CAnsatz ist die Eclipse Bundle-Versionierung . Eclipse-Bundles haben eher ein viertes Segment:

In Eclipse bestehen Versionsnummern aus vier (4) Segmenten: 3 Ganzzahlen und einer jeweils benannten Zeichenfolge major.minor.service.qualifier. Jedes Segment erfasst eine andere Absicht:

• Das Hauptsegment zeigt einen Bruch in der API an
• Das kleine Segment zeigt "extern sichtbare" Änderungen an
• Das Service-Segment zeigt Fehlerbehebungen und die Änderung des Entwicklungsstroms an
• Das Qualifikationssegment gibt einen bestimmten Build an

Es gibt auch das Datum Versionsschema , zum Beispiel: YYYY.MM, YY.MM,YYYYMMDD

Es ist sehr informativ, da ein erster Blick einen Eindruck über das Erscheinungsdatum vermittelt. Aber ich bevorzuge das xyz-Schema, weil ich immer den genauen Punkt eines Produkts in seinem Lebenszyklus wissen möchte (Major.minor.release)

Die grundlegende Antwort lautet "Es kommt darauf an".

Was ist Ihr Ziel bei der Versionierung? Viele Leute verwenden version.revision.build und bewerben nur version.revision in der Welt, da dies eher eine Release-Version als eine Dev-Version ist. Wenn Sie die Check-in-Version verwenden, werden Sie schnell feststellen, dass Ihre Versionsnummern groß werden.

Wenn Sie Ihr Projekt planen, würde ich die Revision für Releases mit geringfügigen Änderungen und die Version für Releases mit größeren Änderungen, Fehlerkorrekturen oder Funktionen / Features erhöhen. Wenn Sie Betaversionen oder nächtliche Build-Versionen anbieten, erweitern Sie die Versionierung um den Build und erhöhen Sie diese mit jeder Version.

Letztendlich liegt es jedoch an Ihnen und es muss für Sie einen Sinn ergeben.

Wie Mahesh sagt: Ich würde eine xyz-Versionierung verwenden

x - Hauptversion y - Nebenversion z - Build-Nummer

Möglicherweise möchten Sie eine Datums- / Uhrzeitangabe hinzufügen, möglicherweise anstelle von z.

Sie erhöhen die Nebenversion, wenn Sie eine andere Version haben. Die Hauptversion wird wahrscheinlich 0 oder 1 bleiben. Sie ändern dies, wenn Sie wirklich größere Änderungen vornehmen (häufig, wenn sich Ihre Software an einem Punkt befindet, an dem sie nicht mehr mit früheren Versionen abwärtskompatibel ist, oder wenn Sie Ihr gesamtes Framework geändert haben).

Sie wissen, dass Sie jederzeit überprüfen können, was andere tun. Open Source-Software ermöglicht in der Regel den Zugriff auf ihre Repositorys. Sie können beispielsweise Ihren SVN-Browser auf http://svn.doctrine-project.org verweisen und sich das von einem realen Projekt verwendete Versionsverwaltungssystem ansehen.

Versionsnummern, Tags, es ist alles da.

Wir folgen einem abc-Ansatz wie:

Erhöhung 'a', wenn einige wesentliche Änderungen in der Anwendung aufgetreten sind. Wie wir die .NET 1.1-Anwendung auf .NET 3.5 aktualisieren

Erhöhung 'b', wenn geringfügige Änderungen vorgenommen werden, z. B. eine neue CR oder Erweiterung.

Erhöhen Sie 'c', wenn der Code einige Fehlerbehebungen enthält.

Ich beginne mit der Versionierung im niedrigsten Segment (kein Hotfix). Ich beschränke dieses Segment nicht auf 10. Wenn Sie keine Builds verfolgen, müssen Sie nur entscheiden, wann Sie ein Inkrement anwenden möchten. Wenn Sie eine QS-Phase haben, wenden Sie möglicherweise ein Inkrement auf das niedrigste Segment und dann das nächste Segment an, wenn es die QA besteht und freigegeben wird. Lassen Sie das oberste Segment für wichtige Verhaltens- / UI-Änderungen.

Wenn Sie wie ich sind, werden Sie es zu einer Mischung der Methoden machen, um dem Fortschritt Ihrer Software zu entsprechen.

Ich denke, das am meisten akzeptierte Muster abc oder abcd, besonders wenn Sie QA / Compliance in der Mischung haben. Ich hatte so viel Schwachsinn, dass ich es für den Mainstream aufgegeben habe.

Ich verfolge keine Builds, daher verwende ich gerne das abc-Muster, es sei denn, es handelt sich um einen Hotfix. Wenn ich einen Hotfix anwenden muss, wende ich Parameter d als Datum mit Uhrzeit an. Ich habe den Zeitparameter als d übernommen, weil es immer das Potenzial mehrerer an einem Tag gibt, an dem die Dinge in der Produktion wirklich explodieren. Ich wende das d-Segment (JJJJMMTTHHNN) nur an, wenn ich für eine Produktionskorrektur divergiere.

Ich persönlich wäre nicht gegen ein Software-Schema von va.b revc, bei dem c JJJJMMTTHHMM oder JJJJMMTT ist.

Alles was gesagt wurde. Wenn Sie sich nur ein Tool zum Konfigurieren und Ausführen schnappen können , müssen Sie sich nicht die Kopfschmerzen nehmen, wenn Sie die Meinungsfacette der Versionierung zusammenfassen müssen, und Sie können einfach "Verwenden Sie das Tool" sagen ... weil jeder im Entwicklungsprozess normalerweise so konform ist .