Underscore: Le trait de soulignement ne suit pas SemVer

Pour citer https://github.com/jashkenas/backbone/issues/2888#issuecomment -29076249 :

Merci, mais suivre strictement la version "sémantique" ne fonctionnerait pas très bien pour Backbone. Étant donné que le projet couvre presque toute la surface et très peu d'éléments internes, presque tout changement donné (correctif, demande d'extraction) apporté à Backbone rompt légèrement la rétrocompatibilité ... même si ce n'est que pour les personnes qui s'appuient sur un comportement précédemment indéfini.

Le reste du commentaire vaut également la peine d'être lu, même si vous n'êtes pas d'accord.

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

@ akre54 Je suis curieux de savoir ce que vous pensez du fait que d'autres projets comme Lo-Dash (alternative Underscore) et ExosJS (alternative Backbone) peuvent suivre semver ?

Étant donné que ces remplacements instantanés _peuvent suivre semver_, cela ne jette-t-il pas une clé dans l'excuse avancée par le noyau Underscore / Backbone?

Quelques choses.

Lo-Dash, pour la plupart, s'en tient aux cowpaths pavés par Underscore, il a donc l'avantage de tenir jusqu'à une version Underscore pour pousser une version bosse pour la parité des fonctionnalités. Les différences par rapport à Underscore ont tendance à se situer davantage dans la catégorie des améliorations et moins dans les modifications importantes avec rupture.

Lo-Dash ajoute beaucoup plus de code de garde pour bc au détriment de l'encombrement du code tandis que Underscore s'efforce d'être concis. Il est plus facile de s'en tirer avec quelques lignes de code supplémentaires lorsque la bibliothèque est plus grande pour commencer (Lo-Dash horloge à 8,7k lignes contre 1,4k pour Underscore.) Il y a aussi beaucoup plus de nettoyage interne qui peut être fait dans Lo- Dash car une grande partie de la logique est interne.

Il est également écrit de manière disproportionnée par un contributeur (vous), alors que les modifications d'Underscore ont tendance à provenir d'un ensemble beaucoup plus diversifié de contributeurs, ce qui signifie que de nouvelles fonctionnalités peuvent arriver à tout moment, et parfois de gros changements de fonctionnalités et des changements rétro-incompatibles surviennent à des moments inopportuns pour un calendrier de diffusion.

Pour l'anecdote, j'ai l'impression que Underscore présente également l'inconvénient du calendrier de publication d'être utilisé dans beaucoup plus de projets pour débutants que Lo-Dash (de par sa nature même, Lo-Dash a tendance à plaire aux développeurs qui ont besoin de sa puissance). Un développeur plus avancé sera plus à l'aise avec les retombées des changements cassants et comprendra peut-être un peu mieux leur raisonnement.

Enfin, en tant que co-auteur et contributeur principal d'Exoskeleton, je serai le premier à vous dire que nous n'avons pas suivi semver non plus. Nous avons également les avantages de Lo-Dash comme décrit ci-dessus.

Lo-Dash, pour la plupart, s'en tient aux cowpaths pavés par Underscore, il a donc l'avantage de tenir jusqu'à une version Underscore pour pousser une version bosse pour la parité des fonctionnalités. Les différences par rapport à Underscore ont tendance à se situer davantage dans la catégorie des améliorations et moins dans les modifications importantes avec rupture.

Qu'est-ce que cela a à voir avec la stratégie de version d'Underscore ? Lo-Dash augmente les versions après semver, c'est pourquoi il passe à la v2.x sur la v3.x.

Lo-Dash ajoute beaucoup plus de code de garde pour bc au détriment de l'encombrement du code tandis que Underscore s'efforce d'être concis.

Qu'est-ce que le code de garde ou le fait d'être concis ont à voir avec la stratégie de version ?

Il est plus facile de s'en tirer avec quelques lignes de code supplémentaires lorsque la bibliothèque est plus grande pour commencer (Lo-Dash horloge à 8,7k lignes contre 1,4k pour Underscore.)

Lo-Dash a des documents en ligne, LOC n'est pas pertinent pour la gestion des versions.

Il y a aussi beaucoup plus de nettoyage interne qui peut être fait dans Lo-Dash car une grande partie de la logique est interne.

Ne peut-on pas en dire autant d'Underscore ?

Il est également écrit de manière disproportionnée par un contributeur (vous), alors que les modifications d'Underscore ont tendance à provenir d'un ensemble beaucoup plus diversifié de contributeurs, ce qui signifie que de nouvelles fonctionnalités peuvent arriver à tout moment, et parfois de gros changements de fonctionnalités et des changements rétro-incompatibles surviennent à des moments inopportuns pour un calendrier de diffusion.

C'est pourquoi Underscore a des responsables pour accepter/rejeter ou repousser jusqu'à une future version.
Encore une fois, pas pertinent pour la gestion des versions.

Pour l'anecdote, j'ai l'impression que Underscore a aussi l'inconvénient d'être utilisé dans beaucoup plus de projets pour débutants que Lo-Dash (de par sa nature même, Lo-Dash a tendance à plaire aux développeurs qui ont besoin de sa puissance).

Je ne suis pas d'accord, Lo-Dash a des milliers de personnes à charge et tous ne peuvent pas être des experts avec ça.

Un développeur plus avancé sera plus à l'aise avec les retombées des changements cassants et comprendra peut-être un peu mieux leur raisonnement.

Parce que Lo-Dash suit semver, les développeurs n'ont pas à faire face aux retombées jusqu'à ce qu'ils passent à une mise à jour de version majeure. Contrairement à Underscore, Lo-Dash ne changera pas sous leurs pieds car ils ont utilisé un ~ pour la plage de versions du package.

Enfin, en tant que co-auteur et contributeur principal d'Exoskeleton, je serai le premier à vous dire que nous n'avons pas suivi semver non plus.

Ensuite, vous devriez retirer cela de sa commercialisation.

Je ne pense pas qu'il y ait une raison pour laquelle Underscore ne pourrait pas suivre semver.
Ne pas le suivre est un mauvais service à vos utilisateurs :frowning:

Si vous voulez être inclus dans npm ou bower, ce n'est pas à débattre. Vous devez utiliser semver. Vous faites une promesse implicite de suivre semver, et si vous ne le faites pas, cela enfreint le code des gens sans avertissement, et c'est mal vu par presque tout le monde.

Nous parlons d'un choix qui brise le code de production. Ce n'est pas cool de jouer à un jeu bâclé avec le temps et l'argent des autres.

Cela signifie que vos numéros de version augmentent plus rapidement. Et alors? C'est un nombre. C'est bien mieux que de casser le panier de production de quelqu'un.

+1 pour semver

Personnellement, je ne pense pas que ce soit "cool" d'avoir _personal_ dans un rapport de bogue. Soit il le fait, soit il ne suit pas la version sémantique. Voici les raisons - bang, bang, bang - pour lesquelles ce serait une bibliothèque encore meilleure si c'était le cas. Voici les raisons - bang, bang - pour lesquelles il est possible pour les responsables d'incrémenter le numéro de version d'une manière conforme à semver.

Après c'est au tour des mainteneurs. Si vous n'êtes pas d'accord avec leur position, il existe des bibliothèques alternatives à utiliser. Vous pouvez bifurquer le projet (comme d'autres l'ont fait). Vous pouvez écrire un article de blog aussi personnel que vous le souhaitez.

Mais essayons d'avoir un désaccord civil.

Je ne comprends pas @raganwald. Qui devient personnel ?

Je n'attaque personne. Je signale que semver fait partie du contrat d'API que vous concluez lorsque vous publiez un package sur npm ou bower.

Si vous brisez ce contrat, vous brisez le code des autres. Ce n'est pas cool.

npm fonctionne très bien car nous sommes tous d'accord sur quelques règles qui permettent à nos modules de bien fonctionner les uns avec les autres. Si vous enfreignez ces règles, vous enfreignez d'autres modules qui essaient de fonctionner avec le vôtre. Vous cassez les applications de production qui reposent sur votre code.

La question n'est pas "devrions-nous utiliser semver?" La question est : « voulons-nous être de bons citoyens dans cet écosystème ?

Le point clé est que sur un projet comme Underscore, _chaque_ changement casse quelqu'un. Si nous supprimons une garde nulle de _.extend (pour utiliser un exemple aléatoire) parce qu'elle cause un bogue pour quelqu'un et qu'elle crée un bogue pour quelqu'un d'autre, est-ce un correctif ? C'est une version mineure ? Majeur?

Pour Underscore et Backbone, je ne pense pas qu'il soit déraisonnable d'épingler vos dépendances. Suivre semver n'est pas obligatoire pour publier sur un packager.

Le point clé est que sur un projet comme Underscore, chaque changement casse quelqu'un.

Vous sautez à l'extrême pour justifier votre position. La réalité est qu'il s'agit d'un équilibre. Il existe une API populaire, des cas extrêmes et un comportement documenté. Il est très possible d'aller pendant un certain temps sans bousculer une version majeure en corrigeant simplement des bogues et en ajoutant des fonctionnalités.

Cela signifie que les mainteneurs doivent réfléchir et planifier. Cela signifie que vous devrez peut-être créer une feuille de route pour les fonctionnalités ou les modifications qui ne peuvent pas être traitées sans casser la rétrocompatibilité et c'est très bien.

Underscore a dépassé les versions de correctifs et introduit des modifications majeures. C'est quelque chose que les mainteneurs peuvent totalement contrôler.

Pour Underscore et Backbone, je ne pense pas qu'il soit déraisonnable d'épingler vos dépendances.

Il devrait y avoir un message/avertissement dans la documentation à coup sûr.

@ akre54 La modification de fonctionnalités _non documentées_ ou de _bogues non documentés_ peut casser le code qui en dépend, mais les utilisateurs s'appuient sur des fonctionnalités et des bogues non documentés à leurs risques et périls.

Ignorer semver met _chaque utilisateur_ de votre API en péril. Les gens corrigent des bogues dans de grands projets open source qui se suivent tout le temps, mais _il est vraiment rare de voir de grands numéros de version dans l'écosystème npm_.

Pourquoi donc?

Parce que _toutes les bonnes API suivent le principe ouvert/fermé_ (ouvert pour l'extension, fermé pour les modifications majeures) aussi étroitement que possible, afin que les utilisateurs puissent suivre le rythme de l'API et que les modifications ne cassent pas le code existant.

Pour ajouter aux anecdotes, mon code a également été cassé par des bosses Underscore dans le passé. Nous avons eu recours à la validation de node_modules pour l'empêcher car --save --save-exact ne suffit pas. Si une dépendance de second niveau s'appuie sur Underscore et utilise une version ^x.y.z , votre application est toujours cassée.

Quant aux numéros de version indiquant la progression, je m'en fiche. L'utilisation de la version 2.1.3 ou 143.3.2 ne fait aucune différence pour moi. La progression et la maturité de la bibliothèque ne sont pas mesurées en numéros de version. Je ne veux tout simplement pas recevoir d'appel téléphonique dimanche après-midi parce que quelqu'un a mis à jour une dépendance qui repose sur underscore@^x.y.z .

:pouce levé: Ouais. @braddunbar soulève un point que je n'ai pas encore abordé - ignorer semver fait de votre paquet un paquet dangereux et virulent, car ce changement de rupture pourrait persister _n'importe où_.

C'est _certainement une exigence onéreuse_ d'obliger les utilisateurs à rechercher les ruptures dans le code tiers qui dépend de votre paquet défectueux.

Selon l'OMI, le véritable progrès et la maturité des bibliothèques se mesurent en fiabilité, et semver contribue grandement à atteindre cet objectif.

Il devrait y avoir un message dans la documentation à coup sûr.

Absolument. Je suis heureux d'en ajouter un si c'est ce que nous décidons.

Je ne suis pas contre un meilleur système de publication (Dieu sait que c'est pénible d'attendre des mois pour que votre petit correctif soit déployé), mais je ne suis pas sûr que "suivre semver" soit _la_ seule bonne réponse.

Pour l'instant, je ne pense pas que ce soit important si c'est la seule bonne réponse. C'est la réponse acceptée par la communauté.

Je ne pense pas que quiconque ait dit que "suivre semver" est la seule bonne réponse pour un meilleur système de publication. Ce que nous avons dit, c'est qu'il s'agit du contrat de l'API npm, et que rompre ce contrat cause des dommages.

@jdalton et @dilvie Comment proposeriez-vous que nous gérions les versions ? Qu'en est-il de l'acceptation des fonctionnalités ? "Utiliser semver" ne nous dit vraiment rien.

Devrions-nous repousser des fonctionnalités telles que _.matches de quelques mois afin de pouvoir attendre les corrections de bogues pour le code actuel, ou devrions-nous le publier maintenant et laisser les gens résoudre les problèmes d'implémentation ?

Je pense que semver ne s'applique tout simplement pas pleinement ici.

Auto-promotion éhontée : utilisez la prochaine mise à jour https://github.com/bahmutov/next-update pour tester d'abord si les dépendances peuvent être mises à jour sans interrompre votre projet. J'ai constamment trouvé des changements cassants dans différents modules malgré la modification *.*.x , donc maintenant je ne fais confiance à aucune version autodéclarée.

Pensez-vous que ce projet est un flocon de neige? Lo-Dash est essentiellement Underscore ++, et suivre semver n'est pas un problème pour @jdalton.

Accepter de nouvelles fonctionnalités :

Cela rompt-il le contrat d'API existant ?

Oui? - bosse le numéro de version majeur.
Non? - bosser le numéro de version mineur.

Acceptation des corrections de bogues/correctifs mineurs :

Cela rompt-il le contrat d'API existant ?

Oui? - bosse le numéro de version majeur.
Non? - numéro de version du correctif.

La façon dont vous choisissez de planifier les sorties officielles dépend entièrement de vous. Assurez-vous simplement que la gestion des versions est plus compatible afin de ne pas casser le code des autres.

D'accord avec @dilvie , par exemple https://github.com/jashkenas/underscore/compare/1.3.3...1.4.0 aurait probablement dû être une bosse majeure car nous avons abandonné la prise en charge des tableaux clairsemés. La prochaine version devrait être une grosse bosse car nous ajouterons une tonne de nouveau sucre via lookupIterator et supprimerons les itérateurs natifs.

Si la documentation d'une fonction doit changer, c'est clairement un changement majeur

J'ai eu une brève discussion à ce sujet à JSconf cette année. Je n'ai pas le temps d'entrer dans les détails, ici, mais :

arrêtez de confondre le "versioning" humain avec la "compatibilité API" face à l'ordinateur (ou vraiment, face au système de construction). Arrête.

Version : "Cette chose que j'aime a de nouvelles fonctionnalités, ou quelque chose d'autre qui devrait m'intéresser quand j'en ai le temps." Il y a un nouvel iPhone. Il y a un nouvel OS X. Il y a un nouvel Ember. Il y a un nouveau rapport révisé sur le schéma de langage algorithmique.

Compatibilité API : "Cette chose a été mise à jour pour corrigerproblème, et cela peut/va rompre le cheminexerce cette chose. La prise d'alimentation de l'iPhone a été remplacée. Fourchettes de ressources obsolètes pour OS X. Ember a déprécié un style de noms d'action. Le schéma est désormais sensible à la casse.

Le dernier se produit _during_, ou _alongside_, l'ancien; mais la première n'est en aucun cas nécessairement dépendante de la seconde ni même liée à celle-ci. Ils devraient être suivis et (si nous voulons vraiment _spécifier_ un système de gestion des versions, bon sang) spécifiés séparément. (le concept de "version sémantique" populaire dans la communauté JS est _particulièrement_ obtus et terrible; mais encore une fois, ce n'est pas quelque chose que je veux approfondir dans le fil de commentaires de quelqu'un d'autre.)

tl;dr : Ils ne gâchent pas votre écosystème en choisissant leur propre chemin. (_Surtout_ lorsque ce chemin est terriblement imparfait.) J'aimerais que plus de projets le fassent. Allez utiliser quelque chose d'autre, si vous êtes à ce point déformé.

@elliottcable - d'accord sur le visage humain par rapport au visage informatique ... Tant que le visage humain ne ressemble en rien au visage de l'ordinateur, la confusion est moins problématique.

Peut-être appeler la prochaine version face à l'homme quelque chose comme "flocon de neige" au lieu de nnn

Totalement en désaccord avec le dernier morceau, cependant. Lorsque vous faites semblant de suivre un contrat d'API, puis que vous le rompez, les choses se cassent. Cela coûte aux autres du temps réel et de l'argent réel. Avec un projet aussi populaire que underscore, il y a potentiellement beaucoup de dégâts réels.

Cela rompt-il le contrat d'API existant ?

Revenez aux tout premiers arguments de ce fil. "Tout dans Underscore est essentiellement une surface", ergo, tout, documenté ou non, fait partie de son contrat API. Tout changement est un changement pour tout le monde.

Lo-Dash, étant "Underscore ++", ne traite pas autant de changements dans les fonctionnalités car il peut suivre en toute sécurité derrière Underscore dans l'élaboration des principales fonctionnalités. Les améliorations de Lo-Dash se situent principalement sous le capot ou en ajoutant quelques méthodes, sans repenser fondamentalement ses fonctionnalités.

@akre54

Comment proposeriez-vous que nous traitions les versions ? Qu'en est-il de l'acceptation des fonctionnalités ? "Utiliser semver" ne nous dit vraiment rien.

Vous pouvez accepter une nouvelle API ou même certaines améliorations de l'API existante. Si vous ajoutez une nouvelle API ou des améliorations (qui ne cassent pas la compatibilité), il s'agit d'une mise à jour de version mineure.

Devrions-nous repousser des fonctionnalités telles que _.matches de quelques mois afin de pouvoir attendre les corrections de bogues pour le code actuel, ou devrions-nous le publier maintenant et laisser les gens résoudre les problèmes d'implémentation ?

Je pense que _.matches est assez simple. Il y aura toujours des corrections de bogues.

Je pense que semver ne s'applique tout simplement pas pleinement ici.

Bien sûr que c'est le cas. Vous commencez à vous glisser dans les soucis du cycle de publication, qui est distinct de semver, mais je vais vous suivre là-bas.

@dilvie : va rester en dehors du reste de l'argument, mais en ajoutant ceci : vraiment, vraiment comme votre suggestion d'aller avec la convention 'nom de version'. (=

Pour la partie humaine, je suis un grand fan de la gestion des versions de style less :

> 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

… associez cela à un joli nom, pour qu'il soit plus clair que nous parlons de version "intéressante", pas de compatibilité API, et vous avez un combo gagnant.

+1 pour le trait de soulignement 42 : "Silly Sheltie".

(En ce qui concerne la partie face au système de construction, j'ai des points de vue controversés sur la compatibilité des API automatisées et génératives. Retirons cette merde des mains des responsables faillibles, s'il vous plaît, et attaquons-la avec une analyse statique ou une exploration dynamique.)

@akre54

Lo-Dash, étant "Underscore ++", ne traite pas autant de changements dans les fonctionnalités car il peut suivre en toute sécurité derrière Underscore dans l'élaboration des principales fonctionnalités.

Qu'est ce que ça veut dire? Lo-Dash traite _plus de changements_ et suit sa propre version distincte de Underscore. Lo-Dash a tellement changé qu'il a dû proposer une version compatible Underscore pour continuer à prendre en charge le remplacement instantané. Nous avons différentes fonctionnalités , méthodes et différents problèmes de compatibilité API.

Les améliorations de Lo-Dash se situent principalement sous le capot ou en ajoutant quelques méthodes, sans repenser fondamentalement ses fonctionnalités.

Ce n'est pas le cas non plus. Lo-Dash se déplace à un rythme plus rapide et se heurte plus fréquemment à la compatibilité dorsale. C'est pourquoi nous passons à la ~v2.x à la ~v3.x. Lo-Dash ressemble à Underscore. Si Lo-Dash peut suivre semver, il en va de même pour Underscore. Je le fais depuis environ 2 ans maintenant. Vos arguments tombent simplement à plat face à la réalité.

J'ai déjà emprunté cette voie, donc je peux vous aider à y arriver aussi.
Pour commencer, la prochaine version d'Underscore ferait un excellent 2.0.

Je suis curieux de savoir comment tout le monde pense que "breaking change" devrait être défini. _Chaque_ nouveau changement de fonctionnalité pour Underscore est un changement radical pour quelqu'un d'autre.

Prenons par exemple toutes les modifications récentes apportées à _.each . Aurions-nous dû cogner lorsque nous avons modifié la valeur de retour de _.each pour retourner la liste d'origine ? Est-ce un correctif ? Une nouvelle fonctionnalité ? Un changement rétro-incompatible ? Il a renvoyé undefined auparavant, il est donc peu probable qu'il ait cassé le code de quelqu'un.

Aurions-nous dû abandonner lorsque nous avons autorisé le helper interne each à être réaffecté en externe ? Cela aurait-il pu casser le code de quelqu'un ? Aucune API publique n'y a changé.

Changer _.each pour éviter les tableaux clairsemés et utiliser des boucles for au lieu des forEach natifs est évidemment une rupture pour certains, mais puisque les tableaux clairsemés sont morts , qui s'en soucie vraiment ? Est-ce quelque chose sur lequel nous devrions pousser une version majeure ? Est-ce un correctif ?

Je pense que nous sommes en retard sur un changement de version majeur (il s'est passé beaucoup de choses en 219 commits ). Une version 2.0 et une solidification de notre politique de version feraient beaucoup ici.

@akre54

Chaque nouvelle fonctionnalité apportée à Underscore est un changement radical pour quelqu'un d'autre.

Pas nécessairement.

Prenons par exemple toutes les modifications récentes apportées à _.each. Aurions-nous dû abandonner lorsque nous avons modifié la valeur de retour de _.each pour renvoyer la liste d'origine ? Est-ce un correctif ?

Ce n'est pas une correction de bogue, c'est une amélioration. Est-ce incassable ? - C'est probablement un changement sûr car il est peu probable que la valeur de retour de _.each ait été invoquée et non quelque chose que les développeurs ont signalé comme étant un obstacle lors du passage à Lo-Dash. En cas de doute, optez pour la rupture ou testez les eaux avec une version RC. Si le changement devait permettre de sortir plus tôt de _.each , je dirais que c'était un changement définitif car les développeurs se heurtaient à cela lors de l'utilisation de CoffeeScript.

Aurions-nous dû cogner lorsque nous avons permis à l'interne de chaque aide d'être réaffecté à l'externe ? Cela aurait-il pu casser le code de quelqu'un ? Aucune API publique n'y a changé.

Je dirais que cela relève des détails de mise en œuvre non documentés. À l'époque, le changement n'autorisait rien de nouveau car Underscore se ramifiait toujours pour les méthodes natives. Ce changement fait partie du groupe plus large de changements dans le post 1.6.0 et peut donc atterrir dans un 2.0.

Changer _.each pour éviter les tableaux clairsemés et utiliser des boucles for au lieu des forEach natifs est évidemment une rupture pour certains, mais puisque les tableaux clairsemés sont morts, qui s'en soucie vraiment ? Est-ce quelque chose sur lequel nous devrions pousser une version majeure ? Est-ce un correctif ?

Cela peut être considéré comme une correction de bogue, mais c'est définitivement un changement de rupture. C'est l'une des choses que les développeurs rencontrent lorsqu'ils passent à Lo-Dash. En raison de la façon dont Underscore était utilisé, l'utilisation de natif lorsqu'il était disponible, cela masquerait l'utilisation de tableaux clairsemés et les développeurs ne rencontreraient le problème que s'ils testaient dans des navigateurs plus anciens. Cependant, avec ce changement, les développeurs seront alertés plus tôt de l'utilisation de leur tableau clairsemé, dans les navigateurs modernes, il y a donc une chance que leur code qui fonctionnait auparavant rencontre un problème.

Je pense que nous sommes en retard sur un changement de version majeur (il s'est passé beaucoup de choses en 219 commits). Une version 2.0 et une solidification de notre politique de version feraient beaucoup ici.

:+1:

breaking change (plural breaking changes)

(Informatique) Modification d'une partie d'un système logiciel susceptible de provoquer la défaillance d'autres composants ; se produit le plus souvent dans des bibliothèques de code partagées utilisées par plusieurs applications
"Impossible de corriger les anciennes entrées sans changement cassant, donc remappez l'ancien vers le nouveau dans la bibliothèque d'importation."

Certains de ces éléments nécessitent réflexion et jugement. Il est peut-être vrai que tous les changements enfreignent le code de quelqu'un, mais si tous les participants acceptent d'utiliser le principe ouvert/fermé comme guide pour ce qui constitue une infraction, cela rend la vie de tout le monde plus facile.

Ainsi, l'ajout d'une propriété ou d'une méthode à l'API n'est généralement pas une modification avec rupture (l'API est ouverte à l'extension, mais fermée aux modifications rétrocompatibles).

Les modifications apportées aux signatures de fonction nécessitent plus de réflexion.

Aurions-nous dû abandonner lorsque nous avons modifié la valeur de retour de _.each pour renvoyer la liste d'origine ?

Était-ce une fonctionnalité documentée de l'API qui servait à quelque chose ? Par exemple, certaines fonctions renvoient undefined lorsque les entrées transmises n'entraîneraient pas de sortie sensible. Cela ne semble pas être le cas avec each ... Donc, probablement pas de rupture.

Éviter les tableaux clairsemés, d'un autre côté, a un plus grand potentiel de modification des valeurs de retour sur lesquelles les développeurs s'appuient, donc clairement, c'est un changement radical, et quiconque a utilisé des tableaux clairsemés s'en soucie.

Les baies clairsemées peuvent ne pas survivre à ES6, mais elles ne sont pas encore mortes.

@akre54
Parfois, la réponse à la question de savoir si un changement se rompt ou non n'est pas simple. Dans ces cas, le contexte, l'historique et les données sont utiles. C'est une chance que j'ai pu utiliser Lo-Dash comme terrain d'essai pour de nouvelles fonctionnalités et voir quels changements déclenchent les développeurs venant d'Underscore. Underscore peut à son tour l'utiliser pour aider à prendre des décisions éclairées sur l'impact des changements.

Au _tout le moins_, le semver suivant aidera à empêcher les modifications majeures de se glisser dans les versions de correctifs et encouragera les développeurs à réfléchir à l'impact de leurs modifications. C'est une victoire pour tout le monde.

@jdalton , acte de classe. :)