Ist es sinnvoll, die letzte Stelle in der Versionsnummer nicht zu setzen?
Wir sind dabei, das Versionsverwaltungs- und Abhängigkeitssystem unserer Middleware (MW) -Software zu ändern, und wir dachten über so etwas nach:
a . b . c . d
a - Hauptversion
b - Abwärtskompatibilität brechen
c - Neue Funktionalität
d - Fehlerbehebung
Aber mit einer kleinen Wendung, da wir die Anzahl der Pakete, die wir aufgrund der Größe der Software und des langsamen Netzwerks an die Clients senden, auf ein Minimum beschränken müssen.
Die Idee war also nur die Bug Fix Nummer bei einer Rückwärtskompatibilität zu ändern. Mit dieser Logik könnten wir ein automatisches System erstellen, das nur dann ein neues Paket generiert, wenn sich die Version, die der Client bereits installiert hat, geändert hat und die Anforderungen des neuen FrontEnd (FE) erfüllt.
Um dieses Szenario besser darzustellen, hier ein paar Beispiele:
Logik erhöhen
Erfordert Paketentscheidungslogik
Obwohl dies eine nicht standardisierte Versionslogik ist, sehen Sie Probleme mit dieser Logik?
2 Antworten
Es ist kein Problem, Versionsnummern zu überspringen (oder komplexe Versionsnummern zu haben), solange Sie über eine interne Logik verfügen, die Ihr gesamtes Unternehmen versteht und anwendet. (Wenn sich die Dinge nicht ändern ... Microsoft wird Version 9 seiner Windows-Systeme überspringen.)
[major]. [minor]. [release]. [build] wird von vielen Firmen ziemlich oft benutzt.
In unserer Firma haben wir ein zusätzliches [build] hinzugefügt, das [privat] genannt wird.
[Major]. [Minor]. [Veröffentlichung]. [Build]. [Privat]
In unserer Logik wird [privat] für die interne Sequenzierung für den Fehlertest verwendet. (Wir brechen absichtlich unseren Code, damit wir auf Bugs testen können.) Aber bevor der Code veröffentlicht wird, muss [privat] auf Null zurückgesetzt werden. Daher verlässt kein Code das Büro, es sei denn, ein 0 sitzt am Ende der Versionsnummer. Es ist eine Erinnerung für Programmierer, um ihre Testcodierung zu entfernen (oder auskommentieren) und es ist eine Erinnerung für Tester, nicht Code zu senden, der nur zum Testen gedacht ist.
In den 80er Jahren las ich auch etwas über die Psychologie der Versionsnummerierung. Einige Unternehmen würden direkt zu [minor] release 3 springen, nur um es so aussehen zu lassen, als ob sie mehr Tests gemacht hätten, als sie es tatsächlich taten. Sie haben es auch vermieden, über 7 hinauszugehen, weil sie so aussahen, als würden sie zu viele Fehler korrigieren und waren anfällig für schrecklich fehlerhaften Code. Diese psychologische Wahrnehmung der Kunden oder Kunden kann ziemlich stark sein und kann eine riesige Debatte zwischen Programmierern (die dazu neigen, Rechtsextremisten zu sein) und Marketing-Leuten (die Logik wie etwas fluffiges nachdenken) behandeln.
In diesem Sinne, um Ihre Frage zu beantworten: Ihre Logik ist fantastisch ... jetzt verkaufen Sie es an Ihre Marketingabteilung. (Oder besser noch ... verkaufe sie nicht an sie, setze sie einfach um und hoffe, dass sie nicht an deine Tür oder Kabine oder Versteck klopfen).
Viel Glück mit Ihrem Design. :)
[ major ]. [ weniger ]. [ release ]. [ build ] (weit akzeptiertes Muster von diesem Beitrag: Ссылка )
Abweichend vom Muster
Sie haben einen bestimmten Grund dafür, also sehe ich keine Probleme. (Ihre spezifische Logik scheint mir auch gut.)
Über das Zurücksetzen der letzten Nummer
Das ist wirklich kein Problem. In der oben verlinkten Antwort können Sie sogar sehen, dass die SVN-Revision als eine zu verwendende Nummer verwendet wird.
Tags und Links java version product versioning