Backbone: Suivre SemVer

Merci, mais suivre strictement le versioning "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) à Backbone rompt la compatibilité descendante d'une certaine manière ... même si ce n'est que pour les personnes qui s'appuient sur un comportement précédemment non défini.

Si nous suivions strictement le versioning "sémantique", ce serait probablement Backbone.js 43.0.0 maintenant - ce qui n'aide personne à évaluer l'avancement réel du projet.

Donc, comme j'aime plaisanter - pas le versioning "sémantique", _le versioning romantique_.

Étant donné un numéro de version MAJOR.MINOR.PATCH, incrémentez :

Version MAJEURE lorsque vous effectuez une nouvelle version majeure, ou mettez à jour et/ou stabilisez de manière significative l'API.
Version MINEURE lorsque vous ajoutez de nouvelles fonctionnalités mineures.
Version PATCH lorsque vous apportez de minuscules modifications, susceptibles de passer inaperçues pour la plupart.

Cela permet aux gens, immédiatement après avoir entendu parler d'une nouvelle version, d'avoir une idée approximative de sa portée. Quant à la rétrocompatibilité — idéalement, _chaque_ version, même les plus importantes, est rétrocompatible. Et quand ils ne peuvent pas l'être, parce qu'une API évolue, cela doit être fait d'une manière qui n'est pas trop difficile à mettre à niveau.

Mais éviter toute modification de l'API, et attendre qu'une version "MAJEURE" soit prête serait un formidable frein au progrès. Et l'alternative consistant à incrémenter fréquemment le numéro de version MAJEUR est incroyablement inutile.

Honnêtement, je préférerais un schéma plus simple qui utilise simplement les numéros de version BIG.SMALL - comme le font la plupart des applications de bureau ... mais je crains que cela ne brise les gestionnaires de paquets et autres outils.

Quel est le problème d'être à Backbone 43.0.0 ?

• Envoyé depuis Chrome 32.0.1700

+1 pour la question spadgos@. Les numéros de version sont arbitraires. Pour une raison quelconque, nous avons des applications Web agiles qui essaient de rester dans les mêmes plages que les systèmes d'exploitation. De nombreuses applications paniquent à l'idée de dépasser 10 ... mais la plupart des projets à partir desquels vous modélisez (Windows, Linux, etc.) ont des cycles de développement d'un an / plusieurs années avant la sortie, donc 1.x -> 2.x est un gros problème. Un projet agile avance très vite, l'incrémentation rapide a aussi du sens.

Je suis également en désaccord avec le raisonnement derrière cela.

Marionette est actuellement en version 1.2.3 et fait de son mieux pour suivre un versionnage sémantique strict. Jusqu'à présent, nous n'avons eu aucun problème même si nous sommes également "toutes superficies". Nous avons ajouté de nouvelles fonctionnalités. Nous avons corrigé des bugs. Mais la v1.0 est toujours compatible avec la v1.2.3. Nous avons différé les tickets pour une version v2 lorsqu'il s'agit de changements d'API ou de comportement attendus.

Les versions majeures avec des changements de rupture ne doivent pas nécessairement se produire chaque semaine lorsqu'une demande d'extraction est acceptée. Celles-ci peuvent (et doivent) être regroupées dans une version majeure qui englobe suffisamment de valeur pour une version volumineuse avec une modification de version majeure.

Dans l'état actuel des choses, la rupture de la compatibilité dans une version v1.1 cause beaucoup de problèmes aux développeurs de plugins et de modules complémentaires, comme l'équipe MarionetteJS. Nous avons dû remplir les comportements avec des correctifs dans notre code, afin que nous puissions rester viables à la fois pour la v1.0 et la v1.1... ce n'est pas une situation amusante. Les effets d'entraînement d'une bibliothèque principale comme Backbone ayant des changements de rupture, sont énormes... ce n'est pas seulement Backbone qui est affecté.

Je suis d'accord que cela ressemble plus à un cas de "je ne veux pas" plutôt que de "je ne peux pas". Les changements de rupture tels que https://github.com/jashkenas/backbone/pull/2461 n'ont aucun réel sentiment d'urgence et auraient pu attendre une mise à jour de version majeure si vous ne vouliez pas le problème 43.0.1.

Pour moi, le plus gros problème avec Backbone qui ne respecte pas semver (entre autres) est dans l'enseignement et l'évangélisation de Backbone. Ce n'est pas génial de dire à un groupe d'étudiants ou de clients potentiels que tout dans votre pile va fonctionner d'une certaine manière... à l'exception de Backbone.

Il y a toujours eu deux énormes mises en garde lors de l'"évangélisation" de Backbone : ce n'est pas un AMD prêt à l'emploi et il ne respecte pas SemVer, alors ne prenez pas les numéros de version au sérieux. L'un d'eux est fixe. Réparons l'autre.

Honnêtement, je préférerais un schéma plus simple qui utilise simplement les numéros de version BIG.SMALL - comme le font la plupart des applications de bureau ... mais je m'inquiéterais de casser les gestionnaires de paquets et autres outils.

@jashkenas, nous pourrions toujours laisser le 3ème chiffre à .0 :)

Cela correspondrait probablement sémantiquement à SemVer un peu plus près que ce que nous faisons actuellement. Peut-être que cela atténuerait certains des snipings crypto-politiques passifs-agressifs sur le fait qu'il est techniquement mal de ne pas suivre SemVer.

Je pense que le point de Bob est juste en ce sens qu'il est plus important d'articuler clairement quel système nous suivons, quel que soit le système que nous suivons.

ps, je ne voulais pas dire que le problème de

:+1: pour le serveur. Je m'intéresse principalement à la version d'un logiciel donné non pas comme un indice de sa progression mais de sa compatibilité.

Généralement, après 1.0 (quand je m'attendrais à ce que les choses soient pour la plupart stables et fonctionnelles), les numéros de version n'ont en grande partie aucun sens en tant qu'indicateurs de progrès. Le logiciel X à la version 10 peut être beaucoup moins mature, avoir moins de fonctionnalités que le logiciel Y à la version 2. Si vous voulez connaître la progression d'un logiciel, vous devez consulter son journal des modifications ou sa feuille de route.

Savoir que Backbone (ou autre) est à 2.4.3 ne signifie rien en termes de fonctionnalités. Cela _devrait_, cependant, signifier que je peux mettre à jour ma version 2.0.4 sans rien casser.

Si nous suivions strictement le versioning "sémantique", ce serait probablement Backbone.js 43.0.0 maintenant - ce qui n'aide personne à évaluer l'avancement réel du projet.

Un problème très mineur / peut-être inexistant. Vous ne suivez pas sever ? Gros problème.

:+1:, semver est indispensable pour un si gros projet.

Je suis avec @knowtheory. 43.0.0 semble un peu étrange, mais je pense que 1.43.0 serait bien et que personne n'aurait de casse surprise après npm install .

Qui se soucie des numéros de version élevés ?
C'est une norme, si vous pouvez l'utiliser, vous devriez l'utiliser.
Je ne comprends même pas pourquoi cette discussion dure si longtemps.

:+1: Cela aurait évité certains des problèmes dans #2996 et #2997, et des problèmes que d'autres ont rencontrés avec plusieurs autres versions de Backbone.

@braddunbar cela (et le reste des raisons "contre") donne l'impression de valoriser l'esthétique du numéro de version par rapport à sa signification réelle.

Merci, mais suivre strictement le versioning "sémantique" ne fonctionnerait pas très bien pour Backbone.

Je pense qu'il s'agit plutôt de savoir si Backbone fonctionne bien pour ses utilisateurs (avec la gestion des dépendances). Quel sever suivant garantirait…

Des versions plus fréquentes aideraient à détecter plus rapidement les bogues d'exception. Je pense que c'est trop demander aux gens d'exécuter constamment des versions de pointe de Backbone juste pour obtenir les corrections de bogues dont ils ont besoin.

+1 @derickbailey

À titre d'exemple, ceux-ci sont depuis la 1.1.0, l'idée derrière les versions de correctifs est que ces correctifs ne devraient pas du tout être nécessaires.

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

Pour les packages en npm ou bower, ce n'est même pas à débattre.

Lorsque vous publiez un package avec npm ou bower, semver fait partie du contrat API que vous concluez. Lorsque vous rompez ce contrat, vous rompez d'autres modules qui dépendent du vôtre. Vous cassez le code de production qui dépend de votre module.

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

Si la réponse est non, cela devrait être annoncé haut et fort, car il n'est pas sûr d'installer simplement votre package comme vous le feriez pour tout autre package qui suit le contrat API.

Lorsque vous publiez un package avec npm ou bower, semver fait partie du contrat API que vous concluez.

Non ce n'est pas. npm install --save [email protected] n'est pas une exigence onéreuse.

@ akre54 Je suis intéressé par votre point de vue sur semver, je sais que @jashkenas en pense mais quel est le vôtre.

@ akre54 Oui, ça l'est. npm suppose que tous les packages du référentiel suivent semver . C'est ainsi qu'il détermine quels packages sont compatibles avec lesquels.

À partir de la doc package.json :

"La version doit être analysable par node-semver, qui est fourni avec npm en tant que dépendance. (npm install semver pour l'utiliser vous-même.)"

Si vos numéros de version _lie_ lorsqu'ils sont interprétés comme semver, ce n'est pas une analyse correcte. Ainsi, vous rompez le package.json et vous rompez la compatibilité avec la façon dont les gens utilisent les versions de package dans l'écosystème npm.

Ce n'est pas seulement une question de préférence personnelle. C'est une question d'interopérabilité des packages.

Est-il possible de forcer votre paquet à jouer s'il n'utilise pas semver ? _Bien sûr_, mais si vous ne l'appelez pas haut et fort en haut de votre fichier readme, peu d'utilisateurs sauront que c'est nécessaire, et lorsque vous introduisez un changement radical, leur code peut très facilement casser.

Une fois que vous publiez vos packages dans des référentiels de packages, la gestion des versions fait partie du contrat d'interopérabilité. Vous ignorez ce contrat aux risques et périls de vos utilisateurs.

npm install --save [email protected] n'est pas une exigence onéreuse.

Sachant lequel des milliers de packages qui entrent dans une application complète, vous devez le faire avec _est_ une exigence onéreuse. Forcer les utilisateurs à verrouiller étroitement les versions de tous leurs packages parce qu'une poignée de modules ne suivent pas les règles _est_ une exigence onéreuse, car cela complique le suivi des corrections de bogues, des correctifs de sécurité, etc.

Il y a de très bonnes raisons de suivre semver. "Mon numéro de paquet pourrait devenir très gros" est une terrible raison de _pas_ utiliser semver. Le suivi de la progression de votre application est une deuxième raison éloignée des versions de package. La fonction la plus importante de la version est de savoir « cette version fonctionnera-t-elle avec mon application ? »

BTW, si votre numéro de colis devenait vraiment gros, c'est peut-être une odeur de code. Vous n'avez qu'à modifier la version majeure lorsque vous effectuez un _changement de rupture_. Un changement décisif par définition est celui qui _brise le principe ouvert/fermé_. Ouvert pour extension, fermé pour modifications importantes. Toutes les bonnes API suivent le principe ouvert/fermé aussi étroitement qu'elles le peuvent raisonnablement, afin que les utilisateurs puissent suivre le rythme de l'API et que les modifications ne cassent pas le code existant.

Je pense que la leçon apprise ici est "n'utilisez pas ~ ou ^ lors de l'extraction de Backbone via package.json"

@ akre54 Je suis intéressé par votre point de vue sur semver

En général, je suis d'accord avec les arguments ici, mais je dois me demander si le remplacement de la version majeure est le meilleur plan d'action sur _chaque_ changement de rupture (et encore une fois, avec Underscore étant principalement une surface, c'est _beaucoup_). Underscore est utilisé dans de nombreuses bibliothèques tierces, et les obliger toutes à suivre des versions volumineuses serait onéreux et périlleux. (Un package publié aujourd'hui devrait-il dépendre d'Underscore jusqu'à la version 2 ? 1.7 ? 1.6.x ? Doit-il épingler ses dépendances au prix de peut-être nécessiter un Underscore distinct du projet principal ?)

Je pense que la leçon apprise ici est "ne pas utiliser ~ ou ^ lors de l'extraction de Backbone via package.json"

Ouais.

Je pense que la leçon apprise ici est "ne pas utiliser ~ ou ^ lors de l'extraction de Backbone via package.json"

J'ai expliqué ci-dessus pourquoi cela ne devrait pas être la leçon à emporter.

Je pense que la leçon apprise ici est "ne pas utiliser ~ ou ^ lors de l'extraction de Backbone via package.json"

C'est ce que vous faites, par conséquent, pour protéger votre code contre la rupture.

La leçon ressemblerait plus à "suivre semver est bon pour tout le monde, ne pas le faire ne l'est pas".

Je peux apprécier la valeur du versioning "romantique". Dommage qu'ils ne cohabitent pas très bien.

Il convient de noter qu'il y aura toujours des projets qui ne suivent pas très strictement le serveur, et ceux qui tentent de le faire mais échouent, de sorte que le système fuit toujours un peu.

Au moins, Backbone est généralement très bon pour ne pas casser les choses.

@dgbeck les choses se cassent tout le temps par versions voir mon commentaire précédent

Je pense donc que l'intérêt de suivre semver dont on n'a pas vraiment parlé est le fait que vous pouvez pousser des fonctionnalités mineures et des corrections de bugs et permettre aux personnes qui en dépendent en amont d'obtenir ces modifications gratuitement.

Pour moi, c'est une grande valeur ajoutée mais cela se fait évidemment au détriment de la complexité pour le mainteneur.