it-swarm-eu.dev

Welche "Versionsnamenskonvention" verwenden Sie?

Sind unterschiedliche Versionsbenennungskonventionen für unterschiedliche Projekte geeignet? Was benutzt du und warum?

Persönlich bevorzuge ich eine hexadezimale Build-Nummer (z. B. 11BCF), die sehr regelmäßig erhöht werden sollte. Und dann für Kunden eine einfache dreistellige Versionsnummer, d. H. 1.1.3.

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.
111
rjstelling

Ich stimme Jeff Atwood selten vollständig zu, aber ich folge eher seiner Meinung zur .NET-Konvention der Versionsnummerierung .

(Hauptversion). (Nebenversion). (Versionsnummer). (Build-Nummer)

Für persönliche Projekte empfinde ich dies meistens als übertrieben. Die wenigen Male, in denen ich an umfangreichen Projekten wie Suchmaschinen in C # gearbeitet habe, habe ich mich an diese Konvention gehalten und konnte sie effektiv als internen Tracker verwenden.

47
Mike B

Die semantische Versionierung ( http://semver.org/ ) verdient hier eine Erwähnung. Es ist eine öffentliche Spezifikation für ein Versionsschema in Form von [Major].[Minor].[Patch]. Die Motivation für dieses Schema besteht darin, die Bedeutung mit der Versionsnummer zu kommunizieren.

90
M. Dudley

Ich benutze es nicht, aber ich habe es gesehen und es ist eine interessante Struktur:

Year.Month.Day.Build

Selbst erklärt.

33
Maniero

Ich versuche, die RubyGems Rational Versioning-Richtlinie zu verwenden, in der:

  • Die Hauptversionsnummer wird erhöht, wenn die Binärkompatibilität unterbrochen wird
  • Die Nebenversionsnummer wird erhöht, wenn neue Funktionen hinzugefügt werden
  • Die Build-Nummer ändert sich für Fehlerkorrekturen.
14
Ken Bloom

Hier ist ein sehr feinkörniger Ansatz zur Versionsnummerierung:

  • N.x.K, wobei N und K ganze Zahlen sind. Beispiele: 1.x.0, 5.x.1, 10.x.33. Wird für Intermediate Builds verwendet.
  • N.M.K, wobei N, M und K ganze Zahlen sind. Beispiele: 1.0.0, 5.3.1, 10.22.33. Wird für Releases verwendet.
  • N.x.x, wobei N eine Ganzzahl ist. Beispiel: 1.x.x. Wird für Support-Zweige verwendet.
  • N.M.x, wobei N und M ganze Zahlen sind. Beispiel: 1.0.x. Wird verwendet für Zweige freigeben.

Hier ist das Bild zur einfachen Veranschaulichung des Versionsnummerierungsansatzes:

Agile version numbering

PA bedeutet Pre-Alpha A bedeutet Alpha B bedeutet Beta AR bedeutet Alpha-Release BR bedeutet Beta-Release RC bedeutet Release Candidate ST bedeutet stabil

Die Vorteile eines solchen Versionsnummerierungsansatzes sind folgende:

  • Es repräsentiert Besonderheiten von agiler Softwareentwicklungslebenszyklus.
  • Es berücksichtigt Besonderheiten von Quellcode-Repository-Struktur.
  • Es ist selbsterklärend für diejenigen, die sich an die Muster gewöhnt haben. Jedes Muster repräsentiert ein anderes Artefakt. Solche Muster können leicht analysiert und für andere Zwecke verwendet werden, z. B. zur Problemverfolgung.
  • Versionsmuster festgelegt, die für den beschriebenen Versionsansatz grundlegend sind, können für Metriken sammeln und Planung verwendet werden.
  • Es konzentriert sich auf die Konzepte Reife und Qualitätsniveau. Sehr oft werden Versionsnummern wie 1.0.0 ohne große Notwendigkeit zugewiesen (wenn sich die Software in Deep Alpha befindet). Der vorgestellte Versionsnummerierungsansatz ermöglicht die Festlegung mehrerer Reifegrade. Im einfachsten Fall hat es nur zwei Ebenen: Intermediate Build (N.x.K) und release (N.M.K). Release bedeutet, dass die Software mit der vollständigen Versionsnummer (N.M.K) hat eine Art Qualitätsmanagementprozess innerhalb des Lieferantenunternehmens/der Organisation/des Teams durchlaufen.
  • Es ist ein Beweis für agile Natur sowohl für die Entwicklung als auch für das Testen.
  • Ermutigt modularer Ansatz zur Softwarestruktur und -architektur.

Es gibt auch komplexere Diagramm , die den Versionsansatz im Detail darstellen. Außerdem finden Sie möglicherweise nützliche Präsentationsfolien , die den Übergang zum Versionierungsansatz beschreiben, und SCMFViz Anwendung, die die Grundprinzipien des Versionsnummerierungsansatzes veranschaulicht. Präsentationsfolien erklären auch, warum es wichtig ist, während der gesamten Laufzeit des Softwareprojekts denselben Versionsansatz beizubehalten.

Persönlich geht meine Einstellung zur Verwendung von Datumsversion anstelle von echten Versionsnummern davon aus, dass Entwickler der Software mit datierten Versionen:

  • Sie wissen nichts über den Lebenszyklus der Softwareentwicklung . Die Entwicklung ist normalerweise agil und iterativ. Der Versionsnummerierungsansatz sollte den iterativen Charakter des Softwareentwicklungsprozesses darstellen.
  • Die Softwarequalität ist egal . Qualitätskontrolle und -sicherung sind agil und iterativ. Genau wie bei der Entwicklung. Die Versionsnummer sollte ein Beweis für die Agilität und Iteration sowohl der Entwicklung als auch der Qualitätskontrolle/-sicherung sein.
  • Kümmern Sie sich nicht um die Architektur oder Idee ihrer Anwendung. Hauptversionsnummer (N in N.M.K) ist sowohl für die Architekturlösung als auch für das zugrunde liegende Prinzip der Anwendung verantwortlich. Die Hauptversionsnummer N ist entsprechend den Änderungen in der Architektur oder den Änderungen der Hauptideen und -prinzipien ihrer Arbeitsweise/Funktionsweise zu ändern.
  • Sie haben keine Kontrolle über ihre Codebasis . Es gibt wahrscheinlich nur einen Zweig (Stamm) und er wird für alles verwendet. Was ich persönlich nicht für richtig halte, da es die Codebasis dazu ermutigt, eine große Müllkippe zu werden.

Dieser Ansatz mag ein wenig kontrovers erscheinen, aber ich glaube, dass dies der einfachste Weg ist, Software geeignete Versionsnummern zu geben.

10
altern

Für jede Hauptversion, die Sie veröffentlichen, ist es nicht ungewöhnlich, dass Sie eine funktionierende Version haben, die Sie intern nennen. Zum Beispiel haben wir bei meinem letzten Job auf eine Hauptversion mit der folgenden von Ubuntu inspirierten Namenskonvention verwiesen:

[kranker Zustand] [alliterativer Tiername]

Was Namen wie "Limp Lamprey", "Wounded Wombat" und "Asthmatic Anteater" gab.

Stellen Sie sicher, dass es nicht zu Ihren Kunden gelangt, es sei denn, es ist ein wirklich cooler Name.

8
Jesse C. Slicer

Generation.Version.Revision.Build (9.99.999.9999)

Die Generation ändert sich selten. Nur ein großes Produkt: DOS -> Windows, komplettes Reengineering.

Die Version ist für große inkompatible Änderungen, neue Funktionen, Änderungen an bestimmten Paradigmen der Software usw. vorgesehen.

Überarbeitungen werden häufig durchgeführt (kleinere Funktionen und Fehlerbehebung).

Build ist eine interne Information.

7
Maniero

git describe bietet eine nette Erweiterung für die von Ihnen gewählte Nummerierungskonvention. Es ist einfach genug, dies in Ihren Build-/Verpackungs-/Bereitstellungsprozess einzubetten.

Angenommen, Sie nennen Ihre getaggten Release-Versionen A.B.C. (major.minor.maintenance). git describe Bei einem bestimmten Commit wird der letzte markierte Vorfahr des Commits gefunden. Anschließend wird die Anzahl der Commits seitdem und die abgekürzte SHA1 des Commits festgelegt:

1.2.3-164-g6f10c

Wenn Sie sich tatsächlich in einer der Versionen befinden, erhalten Sie natürlich nur das Tag (1.2.3).

Dies hat den netten Vorteil, dass Sie genau wissen , aus welcher Quelle Sie erstellt haben, ohne jeden einzelnen Build selbst nummerieren zu müssen.

6
Cascabel

Ich bevorzuge Versionsnummern, die eine semantische Bedeutung haben. Solange Sie die Versionsnummer verwenden können, um mit einer bestimmten Version gemeldete Fehler an Änderungen zu verfolgen, die im Quellcode (und in Ihrem Aktivitätsmanagementsystem) aufgetreten sind, verwenden Sie wahrscheinlich die richtige Methode.

Ich benutze .NET, also bleibe ich beim .NET-Versionsnummerierungssystem, aber ich versuche, den Zahlen so eine semantische Bedeutung zu geben

major.minor.build.revision

  • major = (bis zum Projekt)
  • moll = (bis zum Projekt)
  • build = Build-Nummer von Hudson (Sie können hier TeamCity oder TeamBuild usw. verwenden)
  • revision = Subversion- oder Basar-Revision (abhängig vom Projekt und dessen Verwendung)

Wir stellen immer sicher, dass die Versionsnummer auf irgendeine Weise sichtbar ist (bei unseren konsolenbasierten Batch-Programmen wird sie auf der Konsole gedruckt und in einer Protokolldatei, Web-Apps normalerweise in der Menüleiste oben).

Auf diese Weise können Kunden, die Probleme melden, anhand der Versionsnummer verfolgen, ob sie die neueste Version verwenden und wie viele Probleme wir mit bestimmten Versionen hatten.

Alles dreht sich um Rückverfolgbarkeit!

2
Jeffrey Cameron

Major.Minor.Public (Build) [Alpha/Beta/Test], wie "4.08c (1290)"

  • Mit Major als Hauptversionsnummer (1, 2, 3 ...)
  • Minor ist eine zweistellige Moll-Version (01, 02, 03 ...). In der Regel wird die Zehnerstelle erhöht, wenn wichtige neue Funktionen hinzugefügt werden, die nur zur Fehlerbehebung dienen.
  • Öffentlich ist die öffentliche Version des Builds (a, b, c, d, e), die sich häufig von der Nebenversion unterscheidet, wenn eine Nebenversion nie als öffentliches Update veröffentlicht wird
  • build ist die tatsächliche Build-Nummer, die der Compiler verfolgt.
  • mit TRIAL, ALPHA, BETA X oder RC X für diese Sonderfälle.
2
GrandmasterB

Wir verwenden Major.Minor.Build # .YYMMDD [Suffix], da wir normalerweise nur einen Produktionsaufbau an einem bestimmten Tag durchführen (verwenden Sie jedoch das Suffix ab/c/d, wenn es mehr als ein Suffix gibt) und das YYMMDD gibt Benutzern/Kunden/Management einen Hinweis auf das Alter des Builds, 6.3.1389 nicht.

Die Hauptzahlen steigen mit bedeutenden Produktmerkmalen (kostenpflichtig).

Kleinere Zahlen nehmen mit Korrekturen/Verbesserungen zu (kostenloses Update).

Build nimmt immer zu; Nicht alle bauen Schiffe, es ist also kein linearer Verlauf.

1
JBRWilkinson
 1.0.0 
 | 
 1.0.1 
 | 
 (Öffentlich 1.0) 1.0.2 ----- 
 |\
 2.0.0 1.1.0 
 | | 
 2.0.1 1.1.1 (öffentlich 1.1) 
 | 
 (Öffentlich 2.0) 2.0.2 ----- 
 |\
 3.0.0 2.1.0 
 | 
 2.1.1 (öffentlich 2.1) 
 | 
 2.2.0 
 | 
 2.2.1 

X.Y.Z Ist unsere interne Versionsnummer. X.Y Ist die öffentliche Versionsnummer, die für unsere Kunden eine Bedeutung hat. Wenn eine X.Y.Z - Version veröffentlicht wird, wird es niemals eine X.Y.(Z+1) - Version geben: Die öffentliche Version ist immer die letzte der Serie.

X wird erhöht, wenn eine Hauptversion veröffentlicht wird.

Y wird für die Wartungszweige dieser Hauptversionen nur für Fehlerkorrekturen verwendet.

Z wird intern verwendet und hat keine feste Bedeutung. Bis jetzt erstelle ich eine neue Z -Version, wenn ich denke, dass die Anwendung eine Reihe von Funktionen enthält, die für Nichtentwickler interessant sind und relativ stabil sind. Auf diese Weise kann ich eine Demo der "letzten bekannten guten Version" der Anwendung zeigen, wenn jemand eine fragt. In naher Zukunft plane ich, die Z -Nummernversionen für die Benennung eines "Ziels" von Funktionen in unserem Bugtracker zu verwenden.

Als Randnotiz verwenden wir maven (mit dem Befehl release), um die Versionsnummer zu erhöhen. Es gibt also auch X.Y.Z-SNAPSHOT - Versionen (die jede Version zwischen X.Y.(Z-1) und X.Y.Z Angeben).

0
barjak