Stößt die schnelle Hauptversion auf ein schlechtes Design?

16

Ich habe vor ein paar Monaten als Junior Programmer angefangen. Das System, an dem wir arbeiten, ist seit ca. 2 Jahren in Produktion. Ich war nicht in das Betteln des Systems und des Designs verwickelt.

Eine Sache, die mir aufgefallen ist, ist, dass die Hauptversion des Systems bereits 11.YZ ist. Aufgrund meiner Erfahrung mit anderen Systemen und Bibliotheken kann ich mich nicht erinnern, dass ein Produkt die Hauptversion so schnell anstößt. Es gibt Produkte, die seit Jahren in 1.XY verfügbar sind und weiterhin Funktionen und Bugfixes erhalten.

Unter der Annahme, dass die semantische Versionierung ordnungsgemäß verwendet wird, bedeutet dies, dass das System schlecht konzipiert ist, da es fast alle vier Monate wichtige Änderungen vornimmt?

versioning semantic-versioning

— user367035
quelle

2

Diese Frage wird davon abhängen, ob diese wesentlichen Veränderungen genügend Nutzen (und Gewinne) bringen, die die hohe Änderungsrate rechtfertigen.

— Rwong

3

Wenn diese Versionsnummer Semver verwendet und das System über eine Bibliothek oder eine andere API verfügt, von der andere Teams oder Organisationen abhängig sind, bedeutet diese hohe Hauptzahl, dass Probleme beim Festschreiben eines stabilen, erweiterbaren API-Designs aufgetreten sind. Dies bedeutet auch, dass die eindeutige Kommunikation von Inkompatibilitäten einen hohen Stellenwert hat, was gut ist. Für alles andere (wie Marketing-Namen, Anwendungsprogramme, Nicht-Semver-Nummern, ...) ist die Nummer bedeutungslos und sollte weitgehend ignoriert werden. Fragen Sie einfach Ihre Mitarbeiter danach, um das Projekt besser kennenzulernen.

— amon

3

@amon Das System wird intern für öffentliche mobile Clients verwendet, die über eine REST-ähnliche API mit dem System kommunizieren. Die Versionierung ist wie gesagt Semver und keine Marketingversion.

— user367035

Die Anzahl spielt keine Rolle, aber ich würde misstrauisch werden, wenn die Versionskennung ein süßes Akronym wie Windows NT oder Windows ME oder XP oder wirklich Windows irgendetwas enthalten würde.

— John Wu

1

@ JohnWu: Die Frage bezieht sich speziell auf die Nummer, also, ja, die Nummer spielt eine Rolle. Genauer gesagt geht es um die Zahl im Rahmen der SemVer, wo die Zahl nicht nur tut Angelegenheit, sondern auch eine genau angegebene Bedeutung hat.

— Jörg W Mittag

14

Unter der Annahme, dass die semantische Versionierung ordnungsgemäß verwendet wird, bedeutet dies, dass das System schlecht konzipiert ist, da es fast alle vier Monate wichtige Änderungen vornimmt?

Nicht unbedingt.

Sie haben in den Kommentaren erwähnt, dass dies eine interne API ist. Das Brechen einer API ist schlecht, weil Sie den Code aller brechen. Aber für eine interne API ist "jeder" nur "Sie", und Sie sind perfekt in der Lage, solche API-Änderungen mit sich selbst zu koordinieren, sodass der Schmerz, der normalerweise mit API-Änderungen verbunden ist, viel geringer ist.

Auch der Durchschnitt könnte massiv irreführend sein: Vielleicht hatten sie in den ersten Tagen der frühen Entwicklung 11 wichtige API-Änderungen und sind seitdem seit 4 Jahren stabil? Mit SemVer können Sie wichtige Änderungen vornehmen, ohne die Hauptzahl zu erhöhen, wenn die Hauptzahl 0 ist, aber dies zwingt Sie nicht dazu. Vielleicht haben sie SemVer von Tag 0 an eingesetzt, sogar während der Prototyping- / Explorationsphase?

— Jörg W. Mittag
quelle

5

Diese Antwort scheint die Frage direkt anzusprechen. Einige der anderen Antworten wären gültig, wenn OP nicht von einer semantischen Versionierung ausgehen würde.

— Joshp

Bemerkenswert ist auch, dass wichtige Änderungen nicht immer von Bedeutung sind. Manchmal sind sie sehr klein (aber dennoch wichtig). Sie könnten daher für die Benutzer nur eine sehr geringe Änderung benötigen. Abhängig davon, wie die API verwendet wird, kann es auch zu erheblichen Änderungen kommen. Manchmal wirkt sich eine Änderung beispielsweise nicht auf alle Benutzer aus. Außerdem können Fehlerkorrekturen zu wichtigen Änderungen führen. Es ist jedoch ideal, diese eher früher als später zu beheben. Und wenn die API intern ist, ist es viel einfacher, mit diesen kleinen Änderungen umzugehen.

— Kat

1

Kurze Antwort

Nein

Lange Antwort

"Manchmal ist eine Zahl nur eine Zahl"

Vergessen Sie "semantische Versionierung", "Rationalität", "Logik" in der gegenwärtigen verrückten Welt

Warum verschlingt Chrome Versionsnummern so schnell?

Die "Versions" -Nummern dienen als Meilensteine für die Verzweigungspunkte und nicht als Hauptversionen, um die Öffentlichkeit so zu beeindrucken, wie andere Entwickler sie verwenden. Und es ist ein ständiger Entwicklungsfluss, mit Features, die bereit oder nicht bereit sind, und kein gelegentliches Ereignis, das viele neue Features zusammenbringt, um ein großes Ereignis zu schaffen

— Fauler Dachs
quelle

7

Das OP hat gesagt, dass sie semantische Versionierung verwenden; warum ignorierst du es dann?

— Jörg W Mittag

-3

Bei Verwendung der semantischen Versionierung muss noch entschieden werden, welche Änderungen als "Haupt" und welche als "Neben" betrachtet werden. Es gibt verschiedene Gründe, die Versionsnummer zu erhöhen oder nicht zu erhöhen.

Systeme mit versprochenen Abwärtskompatibilitäten könnten bei den meisten Updates die Hauptversionsnummer erreichen, nur weil es in einigen mehr oder weniger esoterischen Fällen zu einer Unterbrechung der Abwärtskompatibilität kommt. Dieselben Systeme könnten fast unbegrenzt an 1.xy festhalten, da viel Aufwand in die Abwärtskompatibilität gesteckt wird und versucht wird, niemals ein abhängiges System zu zerstören. Beide Ansätze zur Versionsnummerierung könnten als "konservativ" angesehen werden, aber beide könnten auch ein Zeichen für ein tiefgreifendes Problem sein.

In anderen Fällen haben Sie tatsächlich einen Veröffentlichungsplan (denken Sie an vierteljährliche Aktualisierungs-CDs, die an Kunden gesendet werden), in dem es sinnvoll ist, die Hauptversionsnummer so zu ändern, dass statt "Version 3.4 / 16.10." Nur "Version 11.0" angezeigt wird. Heutzutage wird immer mehr Software in kurzen Zeitabständen veröffentlicht, sodass Release-Pläne weniger ein Grund sind, sich an ein bestimmtes Versionsschema zu halten. Ich habe dies in großen Lagersystemen gesehen, die nur einen Ausfalltag pro Quartal (normalerweise einen Sonntag) für die interne IT ermöglichen. Dieser Tag ist der Bereitstellungstag und wird jedes Mal mit einer neuen Hauptversion gekennzeichnet.

Einige Programme weisen externe Abhängigkeiten auf , die von äußerster Wichtigkeit sind, da der Benutzer beide gleichzeitig aktualisieren muss. Wenn Sie ein Word-Addon haben, das nur mit Word 2010 und einem anderen für Word 2013 funktioniert, möchten Sie möglicherweise Ihre Hauptversionsnummern mit der von MS-Word synchronisieren. In diesem Fall sind die Hauptnummern so wichtig, da einige Ihrer Benutzer hinter Ihrem normalen Update-Zeitplan zurückbleiben, da sie nicht auf die aktuellste Version von Word aktualisiert haben (oder auf was auch immer Sie sich sonst verlassen: SAP, Dynamics, etc).

Manchmal bestimmen andere externe Faktoren die Versionsnummern. Wenn Sie über eine Steuersoftware verfügen, werden möglicherweise jährliche Aktualisierungen vorgenommen, die dem Steuergesetz entsprechen (das in der Regel am 1. Januar in Kraft tritt). Solche Systeme werden Hauptversionen haben, die sich genau einmal im Jahr ändern - nicht weil dies der Aktualisierungsplan ist, sondern weil dies für den Kunden von anderer Bedeutung ist: Wenn Sie Ihre Steuern für 2016 erheben, sollten Sie ein Programm haben, das auf das Steuergesetz für 2016 aktualisiert wird.

Letztendlich sind die Versionsnummern von so vielen Faktoren abhängig - oftmals spezifisch für eine Domain -, dass die Nummer allein nichts über den Zustand Ihrer Codebasis aussagt. Es ist ein viel besserer Ansatz, zu sehen, wann, warum und wie Bereitstellungen stattfinden - und wie reibungslos dies geschieht. Wenn Sie ein größeres Update für 10.000 Kunden einführen und ein paar Anrufe tätigen können, ist das wahrscheinlich in Ordnung. Wenn Sie 10 Kunden einen kleinen Patch zur Verfügung stellen und aus diesem Grund Überstunden leisten müssen, stimmt wahrscheinlich etwas nicht.

— Hazzit
quelle

3

"Bei Verwendung der semantischen Versionierung muss noch entschieden werden, welche Änderungen als" Haupt "und welche als" Neben "betrachtet werden." - Nein, gibt es nicht; das ist in der Spezifikation genau definiert. "Es gibt verschiedene Gründe, die Versionsnummer zu erhöhen oder nicht zu erhöhen." - Nein, gibt es nicht; Es gibt genau einen Grund, die Hauptzahl zu erhöhen (worum es bei dieser Frage geht), und sie ist in der Spezifikation genau definiert.

— Jörg W Mittag

1

@ JörgWMittag Entweder lese ich es falsch oder die Spezifikation sagt ausdrücklich, wann Sie die Versionsnummern anstoßen MÜSSEN, aber es sagt nichts darüber, wann Sie KÖNNEN.

— Hazzit

-4

Die Übereinstimmung über die Bedeutung von Versionsnummern ist in der Tat major.minor.revision.buildnumber

Wenn der Major schnell ansteigt, kann es sein, dass der Entwickler all diese neuen Ideen hat und wirklich hart arbeitet.

In der Geschäftswelt kann es jedoch andere Gründe geben, die Hauptversionsnummer zu erhöhen. Mögen

Der Umsatz ist rückläufig, Kunden / Benutzer warten vor dem Upgrade auf die nächste große Hauptversion.
Der Vertrag besagt, dass Kunden zu geringfügigen Aktualisierungen berechtigt sind. Der Verkäufer kann diese nicht in Rechnung stellen, daher wird eine geringfügige Verbesserung als wesentliches Produkt-Upgrade verkauft.
Konkurrent X ist schon etwas länger im Spiel, daher ist die Hauptversionsnummer zufällig höher als Ihre. Dies macht es so, als ob Sie zurückbleiben, Sie müssen "aufholen".

— Martin Maat
quelle

6

Die Frage ist mit einer semantischen Versionierung versehen , das OP erwähnt die semantische Versionierung in der Frage und hat in den Kommentaren bekräftigt, dass sie die semantische Versionierung verwendet. Die SemVer-Spezifikation sagt sehr deutlich aus, wann Hauptversionen inkrementiert werden. Keiner Ihrer "anderen Gründe" trifft zu.

— Jörg W Mittag