it-swarm.com.de

Best Practice: Software-Versionierung

Gibt es Richtlinien oder Best Practices, wie Sie eine Software versionieren können, die Sie in Ihrer Freizeit zum Spaß entwickelt haben, die aber dennoch von einigen Leuten verwendet werden? Ich denke, es ist notwendig, solche Software zu versionieren, damit Sie wissen, über welche Version man spricht (z. B. zur Fehlerbehebung, Unterstützung usw.).

Aber wo starte ich die Versionierung? 0.0.0? oder 0,0? Und wie erhöhe ich dann die Zahlen? Hauptversion.kleine Änderung? und sollte kein Commit für ein Versionskontrollsystem eine andere Version sein? oder nur für produktiv genutzte versionen?

212

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 inkrementieren, liegt ganz bei Ihnen. Verwenden Sie jedoch die Major- und Moll-Build-Nummerierung als Richtlinie.

Es ist nicht erforderlich, dass jede Version, die Sie für die Quellcodeverwaltung festlegen, eine andere Version ist - 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 die 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 sich bei jedem Einchecken/Festschreiben erhöht (aber ich denke, das geht zu weit).

125
ChrisF

Ich würde ... benutzen x.y.z Art der Versionierung

x - Hauptversion
y - kleinere Version
z - Build-Nummer

63
Mahesh Velaga

Ich folge grundsätzlich diesem Muster:

  • ab 0.1.0

  • wenn es fertig ist, verzweige ich den Code in das Quell-Repo, tagge 0.1.0 und erstelle den 0.1.0-Zweig, der Kopf/Rumpf wird zu 0.2.0-Snapshot oder so ähnlich

  • Ich füge neue Funktionen nur dem Trunk hinzu, aber Backport-Korrekturen am Zweig und mit der Zeit veröffentliche 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 ...

42
Bozhidar Batsov

Ich verwende diese Regel für meine Bewerbungen:

x.y.z

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 Fehlerkorrekturen enthält.

Beispiel:

  • Bei einer neuen Anwendung beginnt die Versionsnummer mit 1.0.0.
  • Wenn die neue Version nur Fehlerkorrekturen 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 Hotfixnummer 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.)
35

Wir benutzen a.b.c.d wo

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

Es gibt auch das Datumsversionsschema , zB: YYYY.MM, YY.MM, YYYYMMDD

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

5
athspk

Noch ein Beispiel für die A.B.C Ansatz ist das Eclipse Bundle Versioning . Eclipse-Bundles haben eher ein viertes Segment:

In Eclipse bestehen die Versionsnummern aus vier (4) Segmenten: 3 Ganzzahlen und eine Zeichenfolge mit dem Namen major.minor.service.qualifier. Jedes Segment erfasst eine andere Absicht:

  • das Hauptsegment zeigt einen Bruch in der API an
  • das untergeordnete Segment zeigt Änderungen an, die von außen sichtbar sind
  • das Service-Segment zeigt Fehlerbehebungen und die Änderung des Entwicklungsstroms an
  • das Qualifikationssegment gibt einen bestimmten Build an
5
cuh

Wir folgen a.b.c wie folgt:

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

erhöhung 'b', wenn geringfügige Änderungen vorgenommen wurden, wie z. B. die Implementierung einer neuen CR oder Verbesserung.

erhöhung 'c', wenn der Code einige Fehler behebt.

2
Amandeep Kirar

Die grundlegende Antwort lautet "Es kommt darauf an".

Was ist Ihr Ziel bei der Versionierung? Viele Leute verwenden version.revision.build und machen nur Werbung für version.revision in der Welt, da dies eine Release-Version und keine 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 erhöhen und die Version für Releases mit wesentlichen Änderungen, Fehlerkorrekturen oder Funktionen/Features erhöhen. Wenn Sie Beta-Releases oder nächtliche Build-Releases anbieten, erweitern Sie die Versionierung um den Build und erhöhen Sie diesen mit jedem Release.

Trotzdem liegt es am Ende des Tages an Ihnen und es muss für Sie einen Sinn ergeben.

2
Lazarus

Wie Mahesh sagt: Ich würde x.y.z-Versionierung verwenden

x - Hauptversion y - Nebenversion z - Build-Nummer

möglicherweise möchten Sie ein Datum und eine Uhrzeit 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 kompatibel ist, oder wenn Sie Ihr gesamtes Framework geändert haben).

2
SirLenz0rlot

Sie können jederzeit überprüfen, 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 Versionssystem ansehen.

Versionsnummern, Tags, es ist alles da.

2

Ich beginne die Versionierung im niedrigsten (nicht Hotfix-) Segment. 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 QA-Phase haben, wenden Sie möglicherweise ein Inkrement auf das unterste Segment an und dann das nächsthöhere Segment, wenn es die QA besteht und freigegeben wird. Belassen Sie das oberste Segment für wichtige Verhaltens-/Benutzeroberflächenänderungen.

Wenn Sie wie ich sind, werden Sie es zu einer Mischung der Methoden machen, um das Tempo des Fortschritts Ihrer Software anzupassen.

Ich denke, das am meisten akzeptierte Muster a.b.c. oder a.b.c.d, besonders wenn Sie QA/Compliance in der Mischung haben. Ich hatte so viele Probleme damit, ein regulärer Bestandteil von Versionen zu sein, dass ich es für den Mainstream aufgegeben habe.

Ich verfolge keine Builds, daher verwende ich gerne das a.b.c-Muster, es sei denn, es handelt sich um einen Hotfix. Wenn ich einen Hotfix anwenden muss, wende ich den Parameter d als Datum mit der Uhrzeit an. Ich habe den Zeitparameter als d übernommen, weil an einem Tag, an dem die Dinge in der Produktion wirklich explodieren, immer das Potenzial mehrerer vorhanden ist. Ich wende das d-Segment (JJJJMMTTHHNN) nur an, wenn ich von einem Produktionsfix abweiche.

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

Das alles sagte. Wenn Sie nur ein Tool abfangen damit konfigurieren und ausführen können, werden Sie von den Kopfschmerzen abgehalten, die Sie haben, wenn Sie die Ansichtsfacette der Versionierung zusammenfassen müssen, und Sie können einfach "das Tool verwenden" sagen ... weil jeder in Der Entwicklungsprozess ist normalerweise so konform.

0
rwheadon