Backbone: Folgen Sie SemVer

Danke, aber das strikte Befolgen der "semantischen" Versionierung würde für Backbone nicht sehr gut funktionieren. Angesichts der Tatsache, dass das Projekt fast die gesamte Oberfläche und nur sehr wenig Interna umfasst, unterbricht fast jede Änderung (Patch, Pull-Request) an Backbone die Rückwärtskompatibilität in gewisser Weise ... selbst wenn nur für die Leute, die sich auf zuvor undefiniertes Verhalten verlassen.

Wenn wir uns strikt an die "semantische" Versionierung halten würden, wäre es jetzt wahrscheinlich Backbone.js 43.0.0 – was niemandem hilft, den tatsächlichen Fortschritt des Projekts

Also, wie ich gerne scherze – nicht "semantische" Versionierung, _romantische Versionierung_.

Erhöhen Sie bei einer Versionsnummer MAJOR.MINOR.PATCH Folgendes:

MAJOR-Version, wenn Sie eine neue Hauptversion erstellen oder die API erheblich aktualisieren und/oder stabilisieren.
MINOR-Version, wenn Sie kleinere neue Funktionen hinzufügen.
PATCH-Version, wenn Sie kleine Änderungen vornehmen, die von den meisten wahrscheinlich unbemerkt bleiben.

Dies ermöglicht es den Leuten, unmittelbar nachdem sie von einer neuen Veröffentlichung erfahren haben, einen groben Eindruck von deren Umfang zu bekommen. Was die Abwärtskompatibilität angeht – idealerweise sind _jede_ Version, auch größere, abwärtskompatibel. Und wenn dies nicht möglich ist, weil sich eine API ändert, sollte dies auf eine Weise erfolgen, die nicht zu schwierig zu aktualisieren ist.

Aber jede Änderung an der API zu vermeiden und darauf zu warten, dass ein "MAJOR"-Release fertig ist, wäre ein enormes Hindernis für den Fortschritt. Und die Alternative, die MAJOR-Versionsnummer häufig zu erhöhen, ist unglaublich wenig hilfreich.

Ehrlich gesagt würde ich ein einfacheres Schema bevorzugen, das nur BIG.SMALL Versionsnummern verwendet — wie die meisten Desktop-Anwendungen es tun ... aber ich würde mir Sorgen machen, dass es Paketmanager und andere Tools beschädigt.

Was ist das Problem bei Backbone 43.0.0?

• Gesendet von Chrome 32.0.1700

+1 für spadgos@-Frage. Versionsnummern sind willkürlich. Aus irgendeinem Grund haben wir agile Web-Apps, die versuchen, in den gleichen Bereichen wie Betriebssysteme zu bleiben. Viele Apps flippen aus, wenn sie über 10 hinausgehen ... aber die meisten Projekte, von denen Sie modellieren (Windows, Linux usw.) ist eine große Sache. Ein agiles Projekt bewegt sich sehr schnell, schnelles Inkrementieren macht auch Sinn.

Ich stimme auch der Argumentation dahinter nicht zu.

Marionette ist gerade auf v1.2.3 und tut sein Bestes, um strenge semantische Versionierung zu befolgen. Bisher hatten wir keine Probleme, obwohl wir auch "alle Flächen" sind. Wir haben neue Funktionen hinzugefügt. Wir haben Fehler behoben. Aber v1.0 ist immer noch mit v1.2.3 kompatibel. Wir haben Tickets für ein v2-Release zurückgestellt, wenn es sich um APIs oder erwartete Verhaltensänderungen handelt.

Major Releases mit Breaking Changes müssen nicht jede Woche erfolgen, wenn ein Pull-Request akzeptiert wird. Diese können (und sollten) in einer Hauptversion zusammengefasst werden, die genug Wert für eine große Version mit einer Hauptversionserweiterung umfasst.

So wie es aussieht, verursacht die Unterbrechung der Kompatibilität in einer v1.1-Version viel Ärger für Plugin- und Add-On-Entwickler wie das MarionetteJS-Team. Wir mussten Verhaltensweisen mit Patches in unserem Code auffüllen, damit wir sowohl für v1.0 als auch für v1.1 lebensfähig bleiben können ... es ist keine lustige Situation. Die Auswirkungen einer Kernbibliothek wie Backbone mit Breaking Changes sind enorm... es ist nicht nur Backbone betroffen.

Ich stimme zu, dass dies eher ein Fall von "will nicht" als "kann nicht" zu sein scheint. Breaking Changes wie https://github.com/jashkenas/backbone/pull/2461 haben keine wirkliche Dringlichkeit und hätten auf ein größeres Versionsupdate warten können, wenn Sie das 43.0.1-Problem nicht haben wollen.

Für mich liegt das größte Problem mit Backbone, das Semver nicht respektiert (unter anderem), darin, Backbone zu lehren und zu evangelisieren. Es ist nicht gut, einer Gruppe von Studenten oder potenziellen Kunden zu sagen, dass alles in Ihrem Stack auf eine bestimmte Weise funktionieren wird ... außer Backbone.

Beim "Evangelisieren" von Backbone gab es schon immer zwei große Vorbehalte: Es ist kein AMD out of the box und es respektiert SemVer nicht, also nimm die Versionsnummern nicht ernst. Einer davon ist fest. Lass uns das andere reparieren.

Ehrlich gesagt würde ich ein einfacheres Schema bevorzugen, das nur BIG.SMALL-Versionsnummern verwendet – wie dies bei den meisten Desktop-Anwendungen der Fall ist … aber ich würde mir Sorgen machen, dass Paketmanager und andere Tools beschädigt werden.

@jashkenas wir könnten die 3. Stelle einfach immer bei .0

Das würde SemVer semantisch wahrscheinlich etwas näher zuordnen als das, was wir gerade tun. Vielleicht würde das einige der passiv-aggressiven kryptopolitischen Auswüchse darüber bremsen, dass es technisch irgendwie falsch ist, SemVer nicht zu folgen.

Ich denke, Bobs Standpunkt ist insofern richtig, als es wichtiger ist, klar zu artikulieren, welchem ​​System wir folgen, unabhängig davon, welchem ​​System wir folgen.

ps Ich wollte nicht andeuten, dass das Problem von @keithamus passiv-aggressiv ist und es tut mir leid, wenn es so

:+1: für Semver. Mich interessiert in erster Linie die Version einer bestimmten Software, nicht als Indiz für ihren Fortschritt, sondern für ihre Kompatibilität.

Im Allgemeinen sind Versionsnummern nach 1.0 (wenn ich erwarte, dass die Dinge größtenteils stabil und funktionierend sind) als Fortschrittsindikatoren weitgehend bedeutungslos. Software X in Version 10 ist möglicherweise viel weniger ausgereift, hat weniger Funktionen als Software Y in Version 2. Wenn Sie über den Fortschritt einer Software Bescheid wissen möchten, müssen Sie sich das Changelog oder die Roadmap ansehen.

Zu wissen, dass Backbone (oder was auch immer) auf 2.4.3 steht, bedeutet nichts in Bezug auf seine Funktionen. Es _sollte_ jedoch bedeuten, dass ich von meiner 2.0.4 upgraden kann, ohne dass etwas kaputt geht.

Wenn wir uns strikt an die "semantische" Versionierung halten würden, wäre es jetzt wahrscheinlich Backbone.js 43.0.0 – was niemandem hilft, den tatsächlichen Fortschritt des Projekts einzuschätzen.

Ein sehr kleines / vielleicht nicht vorhandenes Problem. Sie folgen dem Server nicht? Großes Problem.

:+1:, semver ist ein Muss für ein so großes Projekt.

Ich bin bei @knowtheory. 43.0.0 sieht ein bisschen seltsam aus, aber ich denke, dass 1.43.0 in Ordnung wäre und niemand nach npm install einen überraschenden Bruch bekommen würde.

Wen kümmert es, dass die Versionsnummern hoch sind?
Es ist ein Standard, wenn Sie ihn verwenden können, sollten Sie ihn verwenden.
Ich verstehe nicht einmal, warum diese Diskussion so lange andauert.

:+1: Es hätte einige der Probleme in #2996 und #2997 verhindert, und Probleme, die andere mit mehreren anderen Backbone-Versionen hatten.

@braddunbar das (und der Rest der Gründe "dagegen") klingt so, als würde die Ästhetik der Versionsnummer über ihre tatsächliche Bedeutung

Danke, aber das strikte Befolgen der "semantischen" Versionierung würde für Backbone nicht sehr gut funktionieren.

Ich denke, es geht mehr darum, dass Backbone für seine Benutzer gut funktioniert (mit Abhängigkeitsmanagement). Welcher folgende Server würde garantieren…

Häufigere Veröffentlichungen würden helfen, Showstopper-Bugs schneller zu erkennen. Ich denke, es ist zu viel von Leuten zu verlangen, ständig Edge-Versionen von Backbone auszuführen, nur um die Bugfixes zu bekommen, die sie brauchen.

+1 @derickbailey

Als Beispiel gibt es diese seit 1.1.0. Die Idee hinter Patch-Releases ist, dass diese Fixes überhaupt nicht benötigt werden.

https://github.com/marionettejs/backbone.marionette/commit/5a498d250d23a68c9c84a1362782edcf8774a1c8

https://github.com/marionettejs/backbone.marionette/commit/baed36bad8357e4379d4d2bc0460fd1375d2c85b

https://github.com/marionettejs/backbone.marionette/commit/e13e912bdda8e056c0e7b5e15d127eff158a48cb#diff -3c2771f47bdfe073ea95bfa54a37a972R167

Bei Paketen in npm oder bower steht dies nicht einmal zur Debatte.

Wenn Sie ein Paket mit npm oder bower veröffentlichen, ist semver Teil des API-Vertrags, den Sie eingehen. Wenn Sie diesen Vertrag brechen, brechen Sie andere Module, die von Ihrem abhängen. Sie unterbrechen Produktionscode, der von Ihrem Modul abhängt.

Die Frage ist nicht: "Sollten wir Semver verwenden?" Die Frage ist: "Wollen wir gute Bürger im Ökosystem sein?"

Wenn die Antwort nein lautet, sollte dies laut und deutlich angekündigt werden, da es nicht sicher ist, Ihr Paket einfach wie jedes andere Paket zu installieren, das dem API-Vertrag folgt.

Wenn Sie ein Paket mit npm oder bower veröffentlichen, ist semver Teil des API-Vertrags, den Sie eingehen.

Nein, ist es nicht. npm install --save [email protected] ist keine lästige Anforderung.

@akre54 Ich bin an Ihrer Perspektive zu Semver interessiert. Ich kenne @jashkenas Gedanken dazu, aber was sind Ihre

@ akre54 Ja, das ist es. npm geht davon aus, dass alle Pakete im Repository semver folgen . So bestimmt es, welche Pakete mit welchen kompatibel sind.

Aus dem package.json Dokument:

"Version muss von node-semver geparst werden können, das mit npm als Abhängigkeit gebündelt ist. (npm install semver, um es selbst zu verwenden.)"

Wenn Ihre Versionsnummern _lie_ sind, wenn sie als semver interpretiert werden, ist das kein korrektes Parsen. Somit brechen Sie den package.json Vertrag und die Kompatibilität mit der Verwendung von Paketversionen im npm-Ökosystem.

Das ist nicht nur eine Frage der persönlichen Vorlieben. Es ist eine Frage der Paket-Interoperabilität.

Ist es möglich, Ihr Paket zu zwingen, nett zu spielen, wenn es keinen Semver verwendet? _Sicher_, das ist es, aber wenn Sie es nicht laut und mutig oben in Ihrer Readme-Datei aussprechen, werden nur wenige Benutzer wissen, dass dies notwendig ist, und wenn Sie eine grundlegende Änderung einführen, könnte ihr Code sehr leicht kaputt gehen.

Sobald Sie Ihre Pakete in Paket-Repositorys veröffentlichen, wird die Versionsverwaltung Teil des Interoperabilitätsvertrags. Sie ignorieren diesen Vertrag auf Gefahr Ihrer Benutzer.

npm install --save [email protected] ist keine lästige Anforderung.

Zu wissen, welches der Tausenden von Paketen, die in eine ausgewachsene Anwendung fließen, muss man mit _ist_ einer lästigen Anforderung tun. Benutzer zu zwingen, die Versionen aller ihrer Pakete streng zu sperren, weil eine Handvoll Module die Regeln nicht befolgen, _ist_ eine lästige Anforderung, weil es die Angelegenheit erschwert, mit Bugfixes, Sicherheitspatches usw. Schritt zu halten ...

Es gibt sehr gute Gründe, semver zu folgen. "Meine Paketnummer könnte wirklich groß werden" ist ein schrecklicher Grund, _nicht_ Semver zu verwenden. Das Verfolgen des Fortschritts Ihrer Anwendung ist ein entfernter zweiter Grund für Paketversionen. Die wichtigste Funktion der Version ist zu wissen: "Funktioniert diese Version mit meiner Anwendung?"

Übrigens, wenn Ihre Paketnummer wirklich groß werden würde, ist das vielleicht ein Code-Geruch. Sie müssen nur die Hauptversion stoßen, wenn Sie eine _breaking change_ vornehmen. Ein Breaking Change ist definitionsgemäß ein Change, der _das Open/Closed-Prinzip durchbricht_. Offen für Erweiterung, geschlossen für Breaking Changes. Alle guten APIs folgen dem Open/Closed-Prinzip so genau wie es vernünftigerweise möglich ist, damit Benutzer mit der API Schritt halten können und Änderungen bestehenden Code nicht beschädigen.

Ich denke, die Lektion, die wir hier gelernt haben, lautet: "Verwenden Sie nicht ~ oder ^ wenn Sie Backbone über package.json einbinden".

@akre54 Ich interessiere mich für Ihre Perspektive zu semver

Im Allgemeinen stimme ich den Argumenten hier zu, aber ich muss mich fragen, ob das Anstoßen der Hauptversion die beste Vorgehensweise bei _jeder_ Breaking Change ist (und wiederum, da Underscore hauptsächlich die Oberfläche ist, ist das _viel_). Underscore wird in vielen Bibliotheken von Drittanbietern verwendet, und es wäre mühsam und gefährlich, sie alle mit großen Versionen Schritt zu halten. (Sollte ein heute veröffentlichtes Paket bis Version 2 von Underscore abhängen? 1.7? 1.6.x? Sollte es seine Abhängigkeiten auf Kosten eines separaten Underscores vom Hauptprojekt fixieren?)

Ich denke, die Lektion, die wir hier gelernt haben, ist "Verwenden Sie nicht ~ oder ^, wenn Sie Backbone über package.json einziehen"

ja.

Ich denke, die Lektion, die wir hier gelernt haben, ist "Verwenden Sie nicht ~ oder ^, wenn Sie Backbone über package.json einziehen"

Ich habe oben skizziert, warum dies nicht die Lektion zum Mitnehmen sein sollte.

Ich denke, die Lektion, die wir hier gelernt haben, ist "Verwenden Sie nicht ~ oder ^, wenn Sie Backbone über package.json einziehen"

Das ist es, was Sie folglich tun, um Ihren Code vor dem Brechen zu schützen.

Die Lektion würde eher lauten: "Semver zu folgen ist gut für alle, es nicht zu tun."

Ich kann den Wert der "romantischen" Versionierung schätzen. Schade, dass sie nicht sehr gut koexistieren.

Es sollte beachtet werden, dass es immer Projekte geben wird, die nicht sehr streng folgen, und solche, die versuchen, es zu verfehlen, so dass das System immer ein wenig undicht wird.

Zumindest ist Backbone im Allgemeinen sehr gut darin, Dinge nicht kaputt zu machen.

@dgbeck Dinge brechen die ganze Zeit pro Version, siehe meinen früheren Kommentar

Ich denke also, der Wert im folgenden Semver, über den nicht wirklich gesprochen wurde, ist die Tatsache, dass ihr kleinere Funktionen und Fehlerkorrekturen vorantreiben und Leuten, die darauf angewiesen sind, erlauben, diese Änderungen kostenlos zu erhalten.

Für mich ist dies ein großer Mehrwert, aber natürlich geht dies auf Kosten der Komplexität für den Betreuer.