Underscore: Der Unterstrich folgt nicht auf SemVer

Um https://github.com/jashkenas/backbone/issues/2888#issuecomment -29076249 zu zitieren:

Danke, aber die strikte Einhaltung der "semantischen" Versionierung würde für Backbone nicht sehr gut funktionieren. Angesichts der Tatsache, dass das Projekt fast nur Oberfläche und sehr wenig Interna ist, bricht fast jede gegebene Änderung (Patch, Pull-Request) an Backbone die Abwärtskompatibilität in gewisser Weise ... und sei es nur für die Leute, die sich auf zuvor undefiniertes Verhalten verlassen.

Der Rest des Kommentars ist ebenfalls lesenswert, auch wenn Sie anderer Meinung sind.

https://github.com/jashkenas/coffeescript/issues/3352#issuecomment -34217211 auch

@akre54 Ich bin gespannt, was Sie darüber denken, dass andere Projekte wie Lo-Dash (Alternative zu Underscore) und ExosJS (Alternative zu Backbone) semver folgen können?

Da diese Drop-in-Ersetzungen _semver_ folgen können, wirft das nicht irgendwie einen Schraubenschlüssel in die Ausrede, die von Underscore/Backbone-Kern vorgeschoben wird?

Paar Sachen.

Lo-Dash hält sich größtenteils an die von Underscore gepflasterten Kuhpfade, sodass es den Vorteil hat, bis zu einer Veröffentlichung von Underscore zu warten, um einen Versionsschub für die Feature-Parität voranzutreiben. Die Unterschiede zu Underscore liegen eher in der Kategorie der Verbesserungen und weniger in wesentlichen Breaking Changes.

Lo-Dash fügt viel mehr Schutzcode für bc auf Kosten von Code-Unordnung hinzu, während Underscore nach Kürze strebt. Es ist einfacher, mit ein paar Zeilen zusätzlichen Codes davonzukommen, wenn die Bibliothek anfangs größer ist (Lo-Dash kommt auf 8,7.000 Zeilen gegenüber 1,4.000 für Underscore.) Es gibt auch viel mehr internes Ausmisten, das in Lo- Strich, da so viel von der Logik intern ist.

Es wird auch überproportional von einem Mitwirkenden (Sie) geschrieben, während die Änderungen von Underscore dazu neigen, von einer viel vielfältigeren Gruppe von Mitwirkenden zu stammen, was bedeutet, dass neue Funktionen jederzeit kommen können und manchmal große Funktionsänderungen und rückwärtsinkompatible Änderungen zu ungünstigen Zeitpunkten kommen einen Veröffentlichungsplan.

Anekdotisch habe ich das Gefühl, dass Underscore auch den Nachteil des Veröffentlichungsplans hat, dass es in viel mehr Anfängerprojekten verwendet wird als Lo-Dash (von Natur aus neigt Lo-Dash dazu, Entwickler anzusprechen, die seine Leistungsfähigkeit brauchen). Ein fortgeschrittenerer Entwickler wird sich wohler mit den Folgen von Breaking Changes auseinandersetzen und ihre Argumentation vielleicht etwas besser verstehen.

Als Co-Autor und Hauptverantwortlicher von Exoskeleton werde ich der Erste sein, der Ihnen mitteilt, dass wir Semver auch nicht verfolgt haben. Wir haben auch die oben beschriebenen Vorteile von Lo-Dash.

Lo-Dash hält sich größtenteils an die von Underscore gepflasterten Kuhpfade, sodass es den Vorteil hat, bis zu einer Veröffentlichung von Underscore zu warten, um einen Versionsschub für die Feature-Parität voranzutreiben. Die Unterschiede zu Underscore liegen eher in der Kategorie der Verbesserungen und weniger in wesentlichen Breaking Changes.

Was hat das mit der Versionsstrategie von Underscore zu tun? Lo-Dash stößt Versionen nach semver an, weshalb es bei v2.x auf v3.x geht.

Lo-Dash fügt viel mehr Schutzcode für bc auf Kosten von Code-Unordnung hinzu, während Underscore nach Kürze strebt.

Was hat Guard Code oder Prägnanz mit Versionsstrategie zu tun?

Es ist einfacher, mit ein paar Zeilen zusätzlichen Codes davonzukommen, wenn die Bibliothek anfangs größer ist (Lo-Dash erreicht 8,7 000 Zeilen gegenüber 1,4 000 für Underscore).

Lo-Dash hat Inline-Dokumente, LOC ist für die Versionierung nicht relevant.

Es gibt auch viel mehr internes Mucking, das in Lo-Dash durchgeführt werden kann, da so viel von der Logik intern ist.

Kann das nicht auch für Underscore gesagt werden?

Es wird auch überproportional von einem Mitwirkenden (Sie) geschrieben, während die Änderungen von Underscore dazu neigen, von einer viel vielfältigeren Gruppe von Mitwirkenden zu stammen, was bedeutet, dass neue Funktionen jederzeit kommen können und manchmal große Funktionsänderungen und rückwärtsinkompatible Änderungen zu ungünstigen Zeitpunkten kommen einen Veröffentlichungsplan.

Aus diesem Grund hat Underscore Betreuer, die akzeptieren/ablehnen oder bis zu einer zukünftigen Veröffentlichung verschieben müssen.
Auch hier nicht relevant für die Versionierung.

Anekdotisch habe ich das Gefühl, dass Underscore auch den Nachteil hat, dass es in viel mehr Anfängerprojekten verwendet wird als Lo-Dash (von Natur aus neigt Lo-Dash dazu, Entwickler anzusprechen, die seine Leistungsfähigkeit benötigen).

Ich bin anderer Meinung, Lo-Dash hat Tausende von Angehörigen und alle können keine Experten darin sein.

Ein fortgeschrittenerer Entwickler wird sich wohler mit den Folgen von Breaking Changes auseinandersetzen und ihre Argumentation vielleicht etwas besser verstehen.

Da Lo-Dash Semver folgt, müssen sich Entwickler nicht mit Fallout befassen, bis sie zu einem großen Versionsupdate springen. Im Gegensatz zu Underscore wird sich Lo-Dash nicht unter ihren Füßen verändern, da sie ein ~ für den Versionsbereich des Pakets verwendet haben.

Als Co-Autor und Hauptverantwortlicher von Exoskeleton werde ich der Erste sein, der Ihnen mitteilt, dass wir Semver auch nicht verfolgt haben.

Dann sollten Sie das aus dem Marketing entfernen.

Ich glaube nicht, dass es einen Grund gibt, warum Underscore semver nicht folgen konnte.
Ihm nicht zu folgen ist ein Bärendienst für Ihre Benutzer :stirnrunzelnd:

Wenn Sie in npm oder Bower aufgenommen werden möchten, steht dies nicht zur Debatte. Sie müssen semver verwenden. Sie geben ein implizites Versprechen, semver zu folgen, und wenn Sie dies nicht tun, bricht das ohne Vorwarnung den Code der Leute, und das wird von so ziemlich jedem verpönt.

Wir sprechen über eine Wahl, die den Produktionscode bricht. Es ist nicht cool, ein schlampiges Spiel mit der Zeit und dem Geld anderer Leute zu spielen.

Das bedeutet, dass Ihre Versionsnummern schneller größer werden. Na und? Es ist eine Zahl. Das ist weitaus besser, als jemandes Produktionseinkaufswagen zu zerstören.

+1 für semver

Ich persönlich finde es nicht „cool“, in einem Fehlerbericht _persönlich_ zu schreiben. Entweder es folgt der semantischen Versionierung oder nicht. Hier sind die Gründe – peng, peng, peng – warum es eine noch bessere Bibliothek wäre, wenn es so wäre. Hier sind die Gründe – peng, peng –, warum es für die Betreuer machbar ist, die Versionsnummer auf eine Weise zu erhöhen, die mit semver übereinstimmt.

Danach liegt es an den Betreuern. Wenn Sie mit ihrer Haltung nicht einverstanden sind, gibt es alternative Bibliotheken, die Sie verwenden können. Sie können das Projekt forken (wie andere es getan haben). Sie können einen Blogbeitrag schreiben, der so persönlich wird, wie Sie möchten.

Aber lassen Sie uns versuchen, eine zivile Meinungsverschiedenheit zu haben.

Ich verstehe @raganwald nicht. Wer wird persönlich?

Ich greife niemanden an. Ich weise darauf hin, dass semver Teil des API-Vertrags ist, den Sie eingehen, wenn Sie ein Paket für npm oder bower veröffentlichen.

Wenn Sie diesen Vertrag brechen, brechen Sie den Kodex anderer Leute. Das ist nicht cool.

npm funktioniert wirklich gut, weil wir uns alle auf ein paar Regeln einigen, die dafür sorgen, dass unsere Module gut miteinander funktionieren. Wenn Sie diese Regeln brechen, brechen Sie andere Module, die versuchen, mit Ihren zu arbeiten. Sie brechen Produktions-Apps, die auf Ihren Code angewiesen sind.

Die Frage ist nicht "sollten wir Semver verwenden?" Die Frage ist: „Wollen wir gute Bürger in diesem Ökosystem sein?“

Der entscheidende Punkt ist, dass bei einem Projekt wie Underscore _jede_ Änderung zu jemandem durchbricht. Wenn wir einen Null-Wächter von _.extend entfernen (um ein zufälliges Beispiel zu verwenden), weil er bei jemandem einen Fehler verursacht und bei jemand anderem einen Fehler verursacht, ist das dann ein Patch? Ist das eine Minor-Version? Wesentlich?

Für Underscore und Backbone halte ich es nicht für unangemessen, Ihre Abhängigkeiten festzulegen. Das Befolgen von semver ist keine Voraussetzung für die Veröffentlichung an einen Packager.

Der entscheidende Punkt ist, dass bei einem Projekt wie Underscore jede Änderung zu irgendjemandem führt.

Sie springen ins Extreme, um Ihre Position zu rechtfertigen. Die Realität ist, dass es ein Gleichgewicht ist. Es gibt beliebte APIs, Grenzfälle und dokumentiertes Verhalten. Es ist sehr gut möglich, eine Zeit lang ohne eine Hauptversion zu spielen, indem man einfach Fehler behebt und Funktionen hinzufügt.

Das bedeutet, dass die Betreuer nachdenken und planen müssen. Das bedeutet, dass Sie möglicherweise eine Roadmap für Funktionen oder Änderungen erstellen müssen, die nicht ohne Unterbrechung der Backkompatibilität angegangen werden können, und das ist in Ordnung.

Underscore hat Patch-Veröffentlichungen verschoben und wichtige Breaking Changes eingeführt. Dies ist etwas, das die Betreuer vollständig kontrollieren können.

Für Underscore und Backbone halte ich es nicht für unangemessen, Ihre Abhängigkeiten festzulegen.

Es sollte auf jeden Fall eine Meldung/Warnung in der Dokumentation geben.

@akre54 Das Ändern von _undokumentierten_ Funktionen oder _undokumentierten Fehlern_ kann Code beschädigen, der darauf angewiesen ist, aber Benutzer verlassen sich auf undokumentierte Funktionen und Fehler auf eigene Gefahr.

Das Ignorieren von semver bringt _jeden Benutzer_ Ihrer API in Gefahr. Leute beheben Fehler in großen Open-Source-Projekten, die ständig auf semver folgen, aber _es ist wirklich selten, große Versionsnummern im npm-Ökosystem zu sehen_.

Warum ist das so?

Weil _alle guten APIs dem Open/Closed-Prinzip_ (offen für Erweiterungen, geschlossen für Breaking Changes) so genau wie möglich folgen, damit Benutzer mit der API Schritt halten können und Änderungen bestehenden Code nicht beschädigen.

Um die Anekdoten zu ergänzen, wurde mein Code in der Vergangenheit auch durch Underscore-Bumps beschädigt. Wir haben darauf zurückgegriffen, node_modules zu investieren, um es zu verhindern, weil --save --save-exact es nicht schneidet. Wenn eine Abhängigkeit der zweiten Ebene auf Underscore basiert und eine ^x.y.z -Version verwendet, ist Ihre App immer noch defekt.

Die Versionsnummern, die den Fortschritt anzeigen, sind mir egal. Die Verwendung von Version 2.1.3 oder 143.3.2 macht für mich keinen Unterschied. Bibliotheksfortschritt und -reife werden nicht in Versionsnummern gemessen. Ich möchte nur keinen Anruf am Sonntagnachmittag, weil jemand eine Abhängigkeit aktualisiert hat, die auf underscore@^x.y.z .

:daumenhoch: Ja. @braddunbar weist auf einen Punkt hin, auf den ich noch nicht gekommen bin – das Ignorieren von semver macht Ihr Paket zu einem gefährlichen, virulenten Paket, da diese bahnbrechende Änderung _überall_ verweilen könnte.

Es ist _definitiv eine lästige Anforderung_, Benutzer zu zwingen, Brüche im Code von Drittanbietern zu suchen, die von Ihrem beschädigten Paket abhängen.

Meiner Meinung nach wird der Fortschritt und die Reife echter Bibliotheken an der Zuverlässigkeit gemessen, und semver trägt wesentlich dazu bei, dieses Ziel zu erreichen.

In der Dokumentation sollte auf jeden Fall eine Meldung stehen.

Bestimmt. Ich füge gerne einen hinzu, wenn wir uns dafür entscheiden.

Ich bin nicht gegen ein besseres Veröffentlichungssystem (Gott weiß, es ist mühsam, monatelang darauf zu warten, dass Ihr kleiner Bugfix bereitgestellt wird), aber ich bin mir nicht sicher, ob "semver folgen" _die_ einzig richtige Antwort ist.

Im Moment glaube ich nicht, dass es darauf ankommt, ob es die einzig richtige Antwort ist. Es _ist_ die von der Community akzeptierte Antwort.

Ich glaube nicht, dass irgendjemand gesagt hat, dass "semver folgen" die einzig richtige Antwort für ein besseres Release-System ist. Was wir gesagt haben, ist, dass es sich um den npm-API-Vertrag handelt und dass das Brechen dieses Vertrags Schaden anrichtet.

@jdalton und @dilvie Wie würden Sie vorschlagen, dass wir mit Veröffentlichungen umgehen? Was ist mit dem Akzeptieren von Funktionen? „Use semver“ sagt uns eigentlich nichts.

Sollten wir Funktionen wie _.matches ein paar Monate verschieben, damit wir auf Bugfixes für den aktuellen Code warten können, oder sollten wir ihn jetzt veröffentlichen und die Leute Implementierungsprobleme ausarbeiten lassen?

Ich denke, semver trifft hier einfach nicht vollständig zu.

Schamlose Eigenwerbung: Verwenden Sie next-update https://github.com/bahmutov/next-update , um zuerst zu testen, ob die Abhängigkeiten aktualisiert werden können, ohne Ihr Projekt zu beschädigen. Ich habe trotz geänderter *.*.x ständig Breaking Changes in verschiedenen Modulen gefunden, daher vertraue ich jetzt keinen selbst deklarierten Versionen.

Glaubst du, dieses Projekt ist eine Schneeflocke? Lo-Dash ist im Grunde Underscore++, und das Folgen von semver ist für @jdalton kein Problem.

Akzeptieren neuer Funktionen:

Bricht es den bestehenden API-Vertrag?

Ja? - Hauptversionsnummer erhöhen.
Nein? - Minor-Versionsnummer erhöhen.

Akzeptieren von Fehlerbehebungen / kleineren Patches:

Wird der bestehende API-Vertrag gebrochen?

Ja? - Hauptversionsnummer erhöhen.
Nein? - Bump-Patch-Versionsnummer.

Wie Sie offizielle Veröffentlichungen planen, liegt ganz bei Ihnen. Stellen Sie einfach sicher, dass die Versionierung semver-kompatibel ist, damit Sie den Code anderer Leute nicht beschädigen.

Einverstanden mit @dilvie , zum Beispiel https://github.com/jashkenas/underscore/compare/1.3.3...1.4.0 sollte wahrscheinlich ein großer Schlag gewesen sein, da wir die Unterstützung für Sparse-Arrays eingestellt haben. Die nächste Version sollte ein großer Schlag sein, da wir eine Tonne neuen Zuckers über lookupIterator hinzufügen und native Iteratoren fallen lassen werden.

Wenn sich die Dokumentation einer Funktion ändern muss, handelt es sich eindeutig um eine wesentliche Änderung

Ich bin dieses Jahr auf der JSconf in eine kurze Diskussion darüber geraten. Ich habe jetzt nicht die Zeit, ins Detail zu gehen, aber:

Hören Sie auf, menschliche „Versionierung“ mit computerorientierter (oder eigentlich Build-System-orientierter) „API-Kompatibilität“ zu verwechseln. Hör einfach auf.

Version: „Dieses Ding, das ich mag, hat neue Funktionen, oder etwas anderes, das mich interessieren sollte, wenn ich Zeit habe.“ Es gibt ein neues iPhone. Es gibt ein neues OS X. Es gibt ein neues Ember. Es gibt einen neuen überarbeiteten Bericht über das Algorithmic Language Scheme.

API-Kompatibilität: „Dieses Ding wurde aktualisiert, um es zu behebenProblem, und dies kann / wird den Weg brechenübt das Ding aus.“ Der Stromstecker des iPhones wurde ersetzt. OS X veraltete Resource-Forks. Ember hat einen Stil von Aktionsnamen als veraltet markiert. Beim Schema wird jetzt zwischen Groß- und Kleinschreibung unterschieden.

Das Letztere geschieht _during_, oder _alongside_, das erstere; aber ersteres ist in keiner Weise notwendigerweise auf letzteres angewiesen oder auch nur mit ihm verwandt. Sie sollten nachverfolgt und (wenn wir wirklich ein Versionsverwaltungssystem _spezifizieren_ wollen, Jesus) separat spezifiziert werden. (Das Konzept der „semantischen Versionierung“, das in der JS-Community beliebt ist, ist _besonders_ stumpfsinnig und schrecklich; aber noch einmal, etwas, auf das ich nicht im Detail in einem Kommentarthread zu jemand anderem eingehen möchte.)

tl;dr: Sie vermasseln Ihr Ökosystem nicht, indem sie ihren eigenen Weg wählen. (_Besonders_ wenn dieser Pfad schrecklich fehlerhaft ist.) Ich wünschte, mehr Projekte würden es tun. Verwenden Sie etwas anderes, wenn Sie so aus der Form geraten sind.

@elliottcable - stimmte über die menschliche gegenüber der Computeransicht zu ... Solange die menschliche Ansicht nicht wie die Computeransicht aussieht, ist das Zusammenführen weniger problematisch.

Nennen Sie die nächste Veröffentlichung mit menschlichem Gesicht vielleicht so etwas wie "Schneeflocke" anstelle von nnn

Dem letzten Teil kann ich aber überhaupt nicht zustimmen. Wenn Sie vorgeben, einem API-Vertrag zu folgen, und ihn dann brechen, geht alles kaputt. Es kostet andere Menschen echte Zeit und echtes Geld. Bei einem so populären Projekt wie underscore wird möglicherweise eine Menge echter Schaden angerichtet.

Bricht es den bestehenden API-Vertrag?

Schauen Sie zurück auf die allerersten Argumente in diesem Thread. "Alles in Underscore ist im Grunde Oberfläche", also alles, dokumentiert und nicht, ist Teil seines API-Vertrags. Jede Veränderung ist eine Veränderung für alle.

Lo-Dash, das "Underscore++" ist, bewältigt nicht annähernd so viele Änderungen an Funktionen, da es bei der Ausarbeitung wichtiger Funktionen sicher hinter Underscore folgen kann. Die Verbesserungen von Lo-Dash liegen hauptsächlich unter der Haube oder im Hinzufügen einiger Methoden, ohne seine Funktionen grundlegend zu überdenken.

@akre54

Wie würden Sie vorschlagen, dass wir mit Veröffentlichungen umgehen? Was ist mit dem Akzeptieren von Funktionen? „Use semver“ sagt uns eigentlich nichts.

Sie können neue APIs oder sogar einige Erweiterungen bestehender APIs akzeptieren. Wenn Sie neue APIs oder Erweiterungen hinzufügen (die die Kompatibilität nicht beeinträchtigen), handelt es sich um ein Minor-Versionsupdate.

Sollten wir Funktionen wie _.matches ein paar Monate verschieben, damit wir auf Bugfixes für den aktuellen Code warten können, oder sollten wir ihn jetzt veröffentlichen und die Leute Implementierungsprobleme ausarbeiten lassen?

Ich denke, _.matches ist ziemlich geradlinig. Es wird immer Bugfixes geben.

Ich denke, semver trifft hier einfach nicht vollständig zu.

Sicher tut es das. Sie fangen an, sich in Bedenken hinsichtlich des Release-Zyklus zu schleichen, der von Semver getrennt ist, aber ich werde Ihnen dort folgen.

@dilvie : Ich werde mich aus dem Rest des Arguments heraushalten, aber das hier einwerfen: Ich mag Ihren Vorschlag, die Konvention „Versionsname“ zu verwenden, wirklich, wirklich. (=

Was den menschlichen Teil betrifft, so bin ich ein großer Fan von Versionsverwaltung im less -Stil:

> less --version
less 418
Copyright (C) 1984-2007 Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Homepage: http://www.greenwoodsoftware.com/less

… verbinden Sie das mit einem hübschen Namen, um besonders deutlich zu machen, dass wir über eine „Interessanz“-Version sprechen, nicht über API-Kompatibilität, und Sie haben eine gewinnende Kombination.

+1 für Underscore 42: „Silly Sheltie.“

(Was den dem Build-System zugewandten Teil betrifft, so habe ich einige kontroverse Ansichten zur automatisierten, generativen API-Kompatibilität. Nehmen wir diese Scheiße bitte aus den Händen fehlbarer Betreuer und greifen sie mit statischer Analyse oder dynamischem Crawling an.)

@akre54

Lo-Dash, das "Underscore++" ist, bewältigt nicht annähernd so viele Änderungen an Funktionen, da es bei der Ausarbeitung wichtiger Funktionen sicher hinter Underscore folgen kann.

Was bedeutet das überhaupt? Lo-Dash befasst sich mit _weiteren Änderungen_ und folgt einer eigenen Versionierung getrennt von Underscore. Lo-Dash hat sich so sehr verändert, dass es einen Underscore-kompatiblen Build anbieten musste, um seine Unterstützung als Drop-In-Ersatz fortzusetzen. Wir haben unterschiedliche Funktionen , Methoden und unterschiedliche API-Kompatibilitätsbedenken.

Die Verbesserungen von Lo-Dash liegen hauptsächlich unter der Haube oder im Hinzufügen einiger Methoden, ohne seine Funktionen grundlegend zu überdenken.

Das ist auch nicht der Fall. Lo-Dash bewegt sich schneller und trifft häufiger auf Rückenkompatibilität. Aus diesem Grund gehen wir von ~v2.x auf ~v3.x über. Lo-Dash ist Underscore-ähnlich. Wenn Lo-Dash auf Semver folgen kann, kann Underscore dies auch tun. Ich mache das jetzt seit ~2 Jahren. Ihre Argumente gehen einfach an der Realität vorbei.

Ich bin diesen Weg schon einmal gegangen, also kann ich euch allen helfen, auch dorthin zu gelangen.
Für den Anfang würde die nächste Underscore-Veröffentlichung eine großartige 2.0 abgeben.

Ich bin neugierig, wie jeder denkt, dass „Breaking Change“ definiert werden sollte. _Jede_ neue Funktionsänderung von Underscore ist eine bahnbrechende Änderung für jemand anderen.

Nehmen wir zum Beispiel all die letzten Änderungen an _.each . Hätten wir stoßen sollen, als wir den Rückgabewert von _.each geändert haben, um die ursprüngliche Liste zurückzugeben ? Ist das ein Bugfix? Eine neue Funktion? Eine rückwärtsinkompatible Änderung? Es hat zuvor undefined zurückgegeben, daher ist es unwahrscheinlich, dass es den Code von irgendjemandem geknackt hat.

Hätten wir stoßen sollen, als wir zugelassen haben, dass der interne each -Helfer extern neu zugewiesen wird? Könnte das jemandes Code geknackt haben? Dort hat sich keine öffentliche API geändert.

Das Ändern _.each zur Vermeidung von Sparse-Arrays und die Verwendung von for-Schleifen anstelle von nativen forEach ist für einige offensichtlich kaputt, aber da Sparse-Arrays tot sind, wen interessiert das wirklich? Ist es etwas, über das wir eine Hauptversion hinausschieben sollten? Ist das ein Bugfix?

Ich denke, wir sind mit einem großen Versionsstoß überfällig (in 219 Commits ist viel passiert). Ein 2.0-Release und eine Festigung unserer Versionspolitik würden hier viel bewirken.

@akre54

Jede neue Funktionsänderung von Underscore ist eine bahnbrechende Änderung für jemand anderen.

Nicht unbedingt.

Nehmen wir zum Beispiel all die letzten Änderungen an _.each. Hätten wir stoßen sollen, als wir den Rückgabewert von _.each geändert haben, um die ursprüngliche Liste zurückzugeben? Ist das ein Bugfix?

Es ist keine Fehlerbehebung, sondern eine Verbesserung. Ist es nicht brechend?-- Es ist wahrscheinlich eine sichere Änderung, da es unwahrscheinlich ist, dass auf den Rückgabewert von _.each vertraut wurde und nicht etwas, was Entwickler als Hindernis beim Wechsel zu Lo-Dash gemeldet haben. Wenn Sie Zweifel haben, brechen Sie auf die Seite oder testen Sie das Wasser mit einem RC-Release. Wenn die Änderung ein vorzeitiges Verlassen von _.each ermöglichen würde, würde ich sagen, dass es eine definitive Breaking Change war, da Entwickler bei der Verwendung von CoffeeScript darauf stoßen.

Hätten wir stoßen müssen, als wir zugelassen haben, dass die internen Helfer extern neu zugewiesen werden? Könnte das jemandes Code geknackt haben? Dort hat sich keine öffentliche API geändert.

Ich würde sagen, das fällt unter undokumentierte Implementierungsdetails. Damals ließ die Änderung nichts Neues zu, da Underscore noch für native Methoden verzweigte. Diese Änderung fällt unter die größere Gruppe von Änderungen in Post 1.6.0, kann also in 2.0 landen.

Das Ändern _.each zur Vermeidung von Sparse-Arrays und die Verwendung von for-Schleifen anstelle von nativen forEach ist für einige offensichtlich kaputt, aber da Sparse-Arrays tot sind, wen interessiert das wirklich? Ist es etwas, über das wir eine Hauptversion hinausschieben sollten? Ist das ein Bugfix?

Es kann als Fehlerbehebung angesehen werden, aber es ist definitiv eine bahnbrechende Änderung. Dies ist eines der Dinge, auf die Entwickler stoßen, wenn sie zu Lo-Dash wechseln. Aufgrund dessen, wie Underscore früher war, würde die Verwendung von nativem, wenn verfügbar, die Verwendung von Sparse-Arrays maskieren, und Entwickler würden auf das Problem nur stoßen, wenn sie in älteren Browsern testen. Mit dieser Änderung werden Entwickler jedoch in modernen Browsern früher auf ihre spärliche Array-Verwendung aufmerksam gemacht, sodass die Möglichkeit besteht, dass ihr zuvor funktionierender Code auf einen Haken trifft.

Ich denke, wir sind mit einem großen Versionsstoß überfällig (in 219 Commits ist viel passiert). Ein 2.0-Release und eine Festigung unserer Versionspolitik würden hier viel bewirken.

:+1:

Breaking Change (Plural Breaking Changes)

(Computing) Eine Änderung in einem Teil eines Softwaresystems, die potenziell zum Ausfall anderer Komponenten führt; tritt am häufigsten in gemeinsam genutzten Codebibliotheken auf, die von mehreren Anwendungen verwendet werden
"Es ist nicht möglich, alte Einträge ohne Breaking Change zu reparieren, also ordnen Sie alte Einträge in der Importbibliothek neu zu neuen zu."

Einiges davon erfordert einiges Nachdenken und Urteilsvermögen. Es mag wahr sein, dass alle Änderungen den Code von irgendjemandem brechen, aber wenn alle Teilnehmer sich darauf einigen, das Open/Closed-Prinzip als Richtlinie dafür zu verwenden, was das Brechen ausmacht, macht es das Leben aller einfacher.

Das Hinzufügen einer Eigenschaft oder Methode zur API ist also im Allgemeinen keine Breaking Change (die API ist offen für Erweiterungen, aber geschlossen für rückwärtsinkompatible Änderungen).

Änderungen an Funktionssignaturen erfordern mehr Überlegungen.

Hätten wir stoßen sollen, als wir den Rückgabewert von _.each geändert haben, um die ursprüngliche Liste zurückzugeben?

War das eine dokumentierte Funktion der API, die einem bestimmten Zweck diente? Beispielsweise geben einige Funktionen undefiniert zurück, wenn die übergebenen Eingaben nicht zu einer sinnvollen Ausgabe führen würden. Das scheint bei each nicht der Fall zu sein ... Also wahrscheinlich nicht kaputt.

Das Vermeiden von Sparse-Arrays hingegen hat ein größeres Potenzial, Rückgabewerte zu ändern, auf die sich Entwickler verlassen, also ist das eindeutig eine bahnbrechende Änderung, und jeder, der Sparse-Arrays verwendet, kümmert sich darum.

Sparse-Arrays überleben ES6 vielleicht nicht, aber sie sind noch nicht tot.

@akre54
Manchmal ist die Antwort darauf, ob eine Änderung kaputt geht oder nicht, nicht einfach. In diesen Fällen helfen Kontext, Verlauf und Daten. Es ist ein Glück, dass ich Lo-Dash als Testgelände für neue Funktionen nutzen und sehen konnte, welche Änderungen Entwickler von Underscore stolpern lassen. Underscore kann dies wiederum nutzen, um fundierte Entscheidungen über die Auswirkungen von Änderungen zu treffen.

Zumindest hilft der folgende Semver zu verhindern, dass wichtige Breaking Changes in Patch-Releases hineinrutschen, und ermutigt Entwickler, über die Auswirkungen ihrer Änderungen nachzudenken. Das ist ein Gewinn für alle.

@jdalton , Klasse handeln. :)