it-swarm-eu.dev

Was bedeuten die Zahlen in einer Version normalerweise (d. H. V1.9.0.1)?

Vielleicht ist das eine dumme Frage, aber ich habe immer angenommen, dass jede Zahl, die durch einen Punkt gekennzeichnet ist, eine einzelne Komponente der Software darstellt. Wenn das stimmt, repräsentieren sie jemals etwas anderes? Ich möchte damit beginnen, den verschiedenen Builds meiner Software Versionen zuzuweisen, aber ich bin nicht wirklich sicher, wie sie strukturiert werden soll. Meine Software besteht aus fünf verschiedenen Komponenten.

110
BeachRunnerFred

In Version 1.9.0.1:

  • 1 : Major Revision (neue Benutzeroberfläche, viele neue Funktionen, konzeptionelle Änderungen usw.)

  • 9 : Kleinere Revision (eventuell Änderung eines Suchfelds, 1 hinzugefügte Funktion, Sammlung von Bugfixes)

  • 0 : Fehlerbehebung

  • 1 : Build-Nummer (falls verwendet) - aus diesem Grund wird das .NET-Framework mit 2.0.4.2709 angezeigt

Es gibt nicht viele Apps, die sich auf vier Ebenen erstrecken, 3 sind normalerweise ausreichend.

159
Dillie-O

Es gibt die Semantic Versioning-Spezifikation

Dies ist die Zusammenfassung von Version 2.0:

Wenn Sie eine Versionsnummer MAJOR.MINOR.PATCH erhalten, erhöhen Sie das:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Zusätzliche Bezeichnungen für Vorabversionen und Build-Metadaten sind als .__ verfügbar. Erweiterungen für das Format MAJOR.MINOR.PATCH.

14
magyk

Es kann sehr willkürlich sein und unterscheidet sich von Produkt zu Produkt. In der Ubuntu-Distribution beispielsweise bezieht sich 8.04 auf 2008.April

In der Regel geben die am weitesten links liegenden Zahlen die Hauptfreigaben an. Je weiter Sie nach rechts gehen, desto geringer ist die Änderung.

13
rkabir
11

Zahlen können nützlich sein, wie in anderen Antworten beschrieben, aber bedenken Sie, wie sie auch ziemlich bedeutungslos sein können ... Sun, Sie kennen Sun, Java: 1.2, 1.3, 1.4, 1.5 oder 5 und dann 6 ..__ Versionsnummern bedeuten etwas. Heutzutage geben die Leute Versionsnummern auf und gehen mit dummen Namen wie "Feisty Feige" (oder so ähnlich) und "Hardy Heron" sowie "Europa" und "Ganymede". Natürlich ist dies weitaus weniger nützlich, weil Ihnen die Jupitermonde vor dem Ende des Programmwechsels ausgehen werden, und da es keine offensichtliche Reihenfolge gibt, können Sie nicht feststellen, welcher neuere ist.

8
stu

Je mehr Punkte, desto kleiner die Veröffentlichung. Darüber hinaus gibt es keinen wirklich soliden Standard - es kann verschiedene Dinge bedeuten, je nachdem, was die Projektbetreuer entscheiden.

WordPress zum Beispiel geht in diese Richtung:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

1.6 bis 2.0 wäre ein großes Release - Funktionen, Schnittstellenänderungen, wesentliche Änderungen an den APIs, ein Bruch von 1.6-Vorlagen und Plugins usw., 2.0 bis 2.0.1 wären ein untergeordnetes Release - möglicherweise wurde ein Sicherheitsfehler behoben. 2.0.2 bis 2.1 wäre ein bedeutendes Release - neue Funktionen im Allgemeinen.

7
ceejayoz

Zahlen können alles bedeuten, was Sie wollen, obwohl sie sich normalerweise nicht auf einzelne Komponenten beziehen, sondern auf Änderungen gegenüber Major oder Minor gegenüber Wartung in Ihrer Version.

Schauen Sie sich diese Ressourcen an:
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html

Prost

4

Versionsnummern repräsentieren normalerweise keine separaten Komponenten. Für manche Leute/Software sind die Zahlen ziemlich willkürlich. Für andere repräsentieren verschiedene Teile der Versionsnummernzeichenfolge unterschiedliche Dinge. Einige Systeme erhöhen beispielsweise Teile der Versionsnummer, wenn sich ein Dateiformat ändert. Daher ist V 1.2.1 mit allen anderen V 1.2-Versionen (1.2.2, 1.2.3 usw.) kompatibel, nicht jedoch mit V 1.3. Letztendlich liegt es an Ihnen, welches Schema Sie verwenden möchten.

3
user9385

In der Datei C # AssemblyInfo.cs können Sie Folgendes sehen:

// Version information for an Assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [Assembly: AssemblyVersion("1.0.*")]
2

release.major.minor.revision wäre meine Vermutung.
Es kann jedoch zwischen den Produkten sehr unterschiedlich sein.

2
Fire Lancer

Das hängt davon ab, aber die typische Darstellung ist die von major.minor.release.build.

Woher:

  • major ist die Hauptversion Ihrer Software, denken Sie an .NET 3.x
  • minor ist die Nebenversion Ihrer Software, denken Sie an .NET x.5
  • release ist die Version dieser Version. In der Regel wird dies durch Bugfixes erhöht
  • build ist eine Zahl, die die Anzahl der von Ihnen durchgeführten Builds angibt.

1.9.0.1 bedeutet zum Beispiel, dass es sich um Version 1.9 Ihrer Software handelt, gefolgt von 1.8 und 1.7 usw., wobei 1.7, 1.8 und 1.9 alle in der Regel kleine Mengen neuer Funktionen neben Bugfixes enthalten. Da es sich um x.x.0.x handelt, handelt es sich um die erste Version von 1.9, und es ist der erste Build dieser Version.

Gute Informationen finden Sie auch im Wikipedia-Artikel zum Thema .

Major.Minor.Bugs

(Oder eine Variation davon)

Fehler sind in der Regel Fehlerbehebungen ohne neue Funktionen.

Geringfügig sind einige Änderungen, die neue Funktionen hinzufügen, das Programm jedoch nicht wesentlich ändern.

Major ist eine Änderung im Programm, die entweder alte Funktionen unterbricht oder so groß ist, dass sich irgendwie ändert, wie Benutzer das Programm verwenden sollen.

2
emeryc

Jeder wählt, was er mit diesen Zahlen machen möchte. Ich war versucht, Releases a.b.c zu nennen, da es sowieso ziemlich dumm ist. Davon abgesehen, funktioniert das, was ich in den letzten 25 Jahren der Entwicklung gesehen habe, auf diese Weise. Angenommen, Ihre Versionsnummer ist 1.2.3.

Die "1" zeigt eine "Hauptversion" an. In der Regel handelt es sich hierbei um eine Erstveröffentlichung, eine große Änderung des Funktionssatzes oder das Umschreiben wesentlicher Teile des Codes. Sobald das Feature-Set festgelegt und zumindest teilweise implementiert ist, gehen Sie zur nächsten Nummer.

Die "2" zeigt eine Veröffentlichung innerhalb einer Serie an. Häufig nutzen wir diese Position, um sich mit Funktionen vertraut zu machen, die in der letzten Hauptversion nicht gelungen sind. Diese Position (2) zeigt fast immer ein Feature-Add an, normalerweise mit Fehlerbehebungen.

Die "3" in den meisten Shops weist auf ein Patch-Release/Bugfix hin. Fast nie, zumindest auf der kommerziellen Seite, deutet dies auf ein bedeutendes zusätzliches Merkmal hin. Wenn Funktionen in Position 3 angezeigt werden, liegt dies wahrscheinlich daran, dass jemand etwas eingecheckt hat, bevor wir wussten, dass wir eine Fehlerbehebungsversion veröffentlichen mussten.

Über die "3" Position hinaus? Ich habe keine Ahnung, warum die Leute so etwas tun, es wird nur verwirrender.

Bemerkenswert ist, dass einige der OSS da draußen alles aus dem Gleichgewicht bringen. Beispielsweise ist Trac Version 10 tatsächlich 0.10.X.X. Ich denke, vielen Leuten in der OSS-Welt mangelt es entweder an Selbstvertrauen oder sie möchten einfach nicht mitteilen, dass sie eine große Veröffentlichung veröffentlicht haben.

1
mclain

Die Benutzer erkennen nicht immer den subtilen Unterschied zwischen Versionsnummern wie 2.1, 2.0.1 oder 2.10 - fragen Sie einen Mitarbeiter des technischen Supports, wie oft er damit Probleme hatte. Entwickler sind detailorientiert und mit hierarchischen Strukturen vertraut, daher ist dies für uns ein blinder Fleck.

Stellen Sie Ihren Kunden möglichst eine einfachere Versionsnummer zur Verfügung.

1
Mark Ransom

Das Paradigma der großen release.minor release.bug-Korrekturen ist ziemlich üblich, denke ich. 

In einigen Supportverträgen für Unternehmen gibt es $$$ (oder einen Verstoß gegen die vertragliche Haftung), die mit der Bezeichnung einer bestimmten Version zusammenhängen. Ein Vertrag kann beispielsweise dazu führen, dass ein Kunde innerhalb eines bestimmten Zeitraums zu einer bestimmten Anzahl von Hauptversionen berechtigt ist, oder verspricht, dass es in einem bestimmten Zeitraum weniger als die x-Anzahl von Nebenversionen gibt oder dass Support für so viele weiterhin verfügbar ist Veröffentlichungen. Unabhängig davon, wie viele Wörter im Vertrag enthalten sind, um zu erklären, was eine Hauptversion gegenüber einer Nebenversion ist, ist dies immer subjektiv und es wird immer Grauzonen geben, was dazu führt, dass der Softwarehersteller das System spielen kann gegen solche vertraglichen Bestimmungen.

1
Will M

Im Falle einer Bibliothek informiert Sie die Versionsnummer über den Kompatibilitätsgrad zwischen zwei Releases und damit, wie schwierig ein Upgrade sein wird.

Ein Bugfix-Release muss die Kompatibilität zwischen Binär-, Quell- und Serialisierungsfunktion gewährleisten.

Kleinere Releases bedeuten unterschiedliche Dinge für verschiedene Projekte, aber normalerweise müssen sie die Kompatibilität der Quellen nicht beibehalten.

Die Hauptversionsnummern können alle drei Formulare durchbrechen.

Ich habe mehr über die Gründe hier geschrieben.

1
Craig P. Motlin

Major.minor.point.build normalerweise. Major und Moll sind selbsterklärend, Punkt ist ein Release für ein paar kleinere Bugfixes und Build ist nur eine Build-ID.

1
Cody Brocious

Normalerweise ist es:

MajorVersion.MinorVersion.Revision.Build

1
Jason Punyon

Jep. Hauptversionen fügen große, neue Funktionen hinzu, können die Kompatibilität beeinträchtigen oder andere Abhängigkeiten aufweisen usw.

Minor-Releases fügen auch Funktionen hinzu, sind jedoch kleinere, manchmal weniger portierte Versionen von Beta-Major-Releases.

Wenn es eine dritte Versionsnummernkomponente gibt, handelt es sich in der Regel um wichtige Bugfixes und Sicherheitsupdates. Wenn es mehr gibt, hängt es wirklich so sehr vom Produkt ab, dass es schwierig ist, eine allgemeine Antwort zu geben.

1
Paweł Hajdan

Die erste Nummer wird normalerweise als Hauptversionsnummer bezeichnet. Es wird im Wesentlichen verwendet, um bedeutende Änderungen zwischen Builds anzuzeigen (d. H. Wenn Sie viele neue Funktionen hinzufügen, erhöhen Sie die Hauptversion). Komponenten mit unterschiedlichen Hauptversionen desselben Produkts sind wahrscheinlich nicht kompatibel.

Die nächste Nummer ist die Nebenversionsnummer. Es kann einige neue Funktionen oder eine Reihe von Fehlerbehebungen oder kleine Architekturänderungen darstellen. Komponenten desselben Produkts, die sich durch die untergeordnete Versionsnummer unterscheiden, können zusammenarbeiten oder möglicherweise nicht zusammenarbeiten.

Die nächste wird normalerweise als Build-Nummer bezeichnet. Dies kann täglich erhöht werden, bei jedem "freigegebenen" Build oder bei jedem Build. Es kann nur geringfügige Unterschiede zwischen zwei Komponenten geben, die sich nur durch die Build-Nummer unterscheiden und normalerweise gut zusammenarbeiten können.

Die letzte Nummer ist normalerweise die Revisionsnummer. Häufig wird dies von einem automatischen Build-Vorgang verwendet oder wenn Sie einmalige "wegwerfbare" Builds zum Testen erstellen.

Wenn Sie Ihre Versionsnummern erhöhen, liegt es an Ihnen, aber sie sollten immer inkrementieren oder gleich bleiben . Sie können alle Komponenten dieselbe Versionsnummer verwenden oder die Versionsnummer nur für geänderte Komponenten erhöhen.

0
Bob King

Die Versionsnummer einer komplexen Software stellt das gesamte Paket dar und ist unabhängig von den Versionsnummern der Teile. Die Gizmo-Version 3.2.5 enthält möglicherweise Foo-Version 1.2.0 und Bar-Version 9.5.4.

Verwenden Sie diese beim Erstellen von Versionsnummern wie folgt:

  1. Erste Nummer ist Hauptversion. Wenn Sie erhebliche Änderungen an der Benutzeroberfläche vornehmen oder vorhandene Schnittstellen brechen müssen (damit Ihre Benutzer ihren Schnittstellencode ändern müssen), sollten Sie zur neuen Hauptversion wechseln. 

  2. Die zweite Zahl sollte anzeigen, dass neue Funktionen hinzugefügt wurden oder dass etwas intern anders funktioniert. (Die Oracle-Datenbank kann beispielsweise entscheiden, eine andere Strategie für das Abrufen von Daten zu verwenden, wodurch die meisten Aufgaben schneller und einige Dinge langsamer werden.) Vorhandene Schnittstellen sollten weiterhin funktionieren und die Benutzeroberfläche sollte erkennbar sein. 

  3. Die Versionsnummerierung hängt weiterhin von der Person ab, die die Software schreibt - Oracle verwendet fünf (!) Gruppen, d. H. Eine Oracle-Version ist so etwas wie 10.1.3.0.5. Ab der dritten Gruppe sollten Sie nur Bugfixes oder geringfügige Funktionsänderungen einführen. 

0
Sten Vesterli
0
Sijin

diejenigen, die weniger variieren, wären für Major.Minor die ersten beiden, danach kann es sich um alles von Build, Revision, Release und beliebigen benutzerdefinierten Algorithmen handeln (wie in einigen MS-Produkten)

0
BlackTigerX

Hier verwenden wir:

  1. Erste Zahl = Gesamtsystemzeitalter. Änderungen alle paar Jahre und stellen normalerweise eine grundlegende Änderung der Technologie oder der Client-Funktionen oder beides dar.
  2. Zweite Nummer = Revision des Datenbankschemas. Ein Inkrement in dieser Anzahl erfordert eine Datenbankmigration und ist daher eine bedeutende Änderung (oder wenn Systeme repliziert werden und das Ändern der Datenbankstruktur einen sorgfältigen Aktualisierungsvorgang erfordert). Wird auf 0 zurückgesetzt, wenn sich die erste Zahl ändert.
  3. Dritte Zahl = nur Softwareänderung. Dies kann normalerweise Client für Client implementiert werden, da das Datenbankschema unverändert bleibt. Wird auf null zurückgesetzt, wenn sich die zweite Zahl ändert.
  4. Versionsnummer der Subversion Wir füllen dies automatisch mit dem TortoiseSVN-Tool auf. Diese Zahl wird nie zurückgesetzt, sondern kontinuierlich erhöht. Damit können wir jederzeit jede Version neu erstellen.

Dieses System ist gut für uns, weil jede Nummer eine klare und wichtige Funktion hat. Ich habe andere Teams gesehen, die sich mit der Frage nach der Haupt-/Nebenanzahl beschäftigten (wie groß die Veränderung ist) und ich sehe keinen Vorteil darin. Wenn Sie keine Datenbankrevisionen nachverfolgen müssen, gehen Sie einfach zu einer 3- oder 2-stelligen Versionsnummer und machen Sie das Leben einfacher!

0
Ewan Makepeace

In Version v1.9.0.1: Dies ist das explizite Versionsschema, das verwendet wird, wenn Sie keinen Namen für die Vorversionen oder das Build wie -alpha, -beta verwenden möchten.

1: Hauptversion, die die Abwärtskompatibilität beeinträchtigen könnte

9: Hinzufügen neuer Funktionen zur Unterstützung Ihrer App sowie Rückwärtskompatibilität mit früheren Versionen.

0: Einige kleinere Fehlerbehebungen

1: Build-Nummer (Vorabnummer)

heutzutage finden Sie jedoch kein solches Versionsschema. Verweisen Sie auf Semantic Versioning [semver2.0] https://semver.org/

0
Mehul Sancheti

Jede Organisation/Gruppe hat ihren eigenen Standard. Das Wichtigste ist, dass Sie sich an die von Ihnen gewählte Schreibweise halten, sonst werden Ihre Kunden verwirrt. Allerdings habe ich normalerweise 3 Zahlen verwendet:

x.yz.bbbbb. Dabei gilt: X: ist die Hauptversion (wichtige neue Funktionen) Y: ist die Nebenversionsnummer (kleine neue Funktionen, kleine Verbesserungen ohne Änderungen an der Benutzeroberfläche) Z: ist das Service Pack (im Wesentlichen das gleiche wie xy, aber mit einigen Fehlerkorrekturen bbbb: ist die Build-Nummer und nur wirklich sichtbar aus der "About Box" mit anderen Details für den Kundensupport.

0
Vasco Duarte

Eine Kombination aus Major, Minor, Patch, Build, Sicherheitspatch usw.

Die ersten beiden sind major & minor - der Rest hängt vom Projekt, der Firma und manchmal auch von der Community ab. In Betriebssystemen wie FreeBSD haben Sie 1.9.0.1_number, um einen Sicherheitspatch darzustellen.

0
Loren Segal

Abhängig von der Sprache haben Delphi und C # beispielsweise unterschiedliche Bedeutungen.

Normalerweise stellen die ersten beiden Zahlen eine Haupt- und eine Nebenversion dar, d. H. 1.0 für die erste echte Version, 1.1 für einige wichtige Bugfixes und kleinere neue Funktionen, 2.0 für eine große neue Feature-Version.

Die dritte Zahl kann sich auf eine "wirklich untergeordnete" Version oder Revision beziehen. 1.0.1 ist nur ein sehr kleiner Bugfix auf 1.0.0. Es kann jedoch auch die Revisionsnummer aus Ihrem Quellcodeverwaltungssystem oder eine ständig wachsende Nummer enthalten, die mit jedem Build inkrementiert wird. Oder ein Datumsstempel.

Ein bisschen mehr Detail hier . "offiziell", in .net sind die 4 Zahlen "Major.Minor.Build.Revision", wohingegen in Delphi "Major.Minor.Release.Build" steht. Ich verwende "Major.Minor.ReallyMinor.SubversionRev" für meine Versionierung.

0
Michael Stum

In der Regel liegt dann number im Format version.major.minor.hotfix vor, nicht bei einzelnen internen Komponenten. Version 1.9.0.1 wäre also Version 1, Hauptversion 9 (von Version 1), Nebenversion (von Version 1.9) 0, Hotfix 1 von (Version 1.9.0).

0
Scott Bevington