La version majeure rapide est-elle une preuve de mauvaise conception?

16

J'ai commencé un travail en tant que programmeur junior il y a quelques mois. Le système sur lequel nous travaillons est en production depuis environ 2 ans. Je n'étais pas impliqué dans la mendicité du système et de la conception.

Une chose que j'ai remarquée, c'est que la version principale du système est déjà 11.YZ. D'après mon expérience de travail avec d'autres systèmes et bibliothèques, je ne me souviens pas avoir vu une version majeure se produire aussi rapidement. Il y a des produits qui existent depuis des années dans 1.XY, et qui reçoivent toujours des fonctionnalités et des corrections de bugs.

En supposant que le versioning sémantique est utilisé correctement, cela indique-t-il que le système est mal conçu car il apporte des changements de rupture majeurs presque tous les quatre mois?

versioning semantic-versioning user367035
la source
2
Cette question dépendra de savoir si ces changements de rupture majeurs apportent suffisamment d'avantages (et de bénéfices) qui justifient le taux de changement élevé.
rwong
3
Si ce numéro de version utilise Semver, et si le système dispose d'une bibliothèque ou d'une autre API dont dépendent d'autres équipes ou organisations, ce nombre majeur élevé signifie qu'il y a eu des problèmes pour s'engager dans une conception d'API stable et extensible. Cela signifie également que des incompatibilités clairement communiquées sont très appréciées, ce qui est une bonne chose. Pour toute autre chose (comme les noms de marketing, les programmes d'application, les numéros non Semver,…), le nombre n'a pas de sens et doit être largement ignoré. Il suffit de demander à vos collègues à ce sujet, dans le cadre de vous apprendre à mieux connaître le projet.
amon
3
@amon Le système est utilisé en interne avec des clients mobiles publics communiquant avec le système via une API de type REST. Le versioning est Semver comme je l'ai mentionné et non la version marketing.
user367035
Le nombre n'a pas d'importance, mais je serais suspect si l'identifiant de version incluait un acronyme mignon, comme Windows NT ou Windows ME ou XP ou vraiment quelque chose de Windows.
John Wu
1
@JohnWu: la question est précisément sur le nombre, donc, oui, le nombre fait la matière. Plus précisément, il est à peu près le nombre dans le contexte de SemVer, où le nombre non seulement fait la matière, mais elle a aussi une signification précise spécifiée.
Jörg W Mittag

Réponses:

14

En supposant que le versioning sémantique est utilisé correctement, cela indique-t-il que le système est mal conçu car il apporte des changements de rupture majeurs presque tous les quatre mois?

Pas nécessairement.

Vous avez mentionné dans les commentaires qu'il s'agit d'une API interne. Briser une API est mauvais, car vous brisez le code de tout le monde. Mais pour une API interne, «tout le monde» n'est que «vous», et vous êtes parfaitement capable de coordonner de tels changements d'API avec vous-même, de sorte que la douleur généralement associée aux changements d'API est bien moins pire.

De plus, la moyenne pourrait être massivement trompeuse: peut-être qu'ils ont eu 11 changements d'API de rupture au cours des deux premiers jours de développement précoce et sont-ils stables depuis 4 ans depuis? SemVer vous permet d'effectuer des changements de rupture sans augmenter le nombre majeur si le nombre majeur est 0, mais cela ne vous y oblige pas. Peut-être ont-ils commencé à utiliser SemVer à partir du jour 0, même pendant les phases de prototypage / exploration?

Jörg W Mittag
la source
5
Cette réponse semble répondre directement à la question. Certaines des autres réponses seraient valables sans l'hypothèse d'OP de versionnage sémantique.
joshp
Il convient également de noter que les changements de rupture ne sont pas toujours majeurs. Parfois, ils sont vraiment assez petits (mais importants). Ils pourraient donc avoir besoin de très peu de changement pour les utilisateurs. En outre, il peut y avoir un assez grand nombre de changements de rupture en fonction de la façon dont l'API est utilisée. Parfois, un changement de rupture n'affectera pas tous les utilisateurs, par exemple. De plus, les corrections de bogues peuvent introduire des changements de rupture, mais il est idéal de les corriger le plus tôt possible. Et si l'API est interne, il est beaucoup plus facile de gérer ces petits changements de rupture.
Kat
1

Réponse courte

Non

Longue réponse

"Parfois, un nombre n'est qu'un nombre"

Oubliez le "versionnage sémantique", la "rationalité", la "logique" dans le monde fou actuel

Pourquoi Chrome engloutit-il les numéros de version si rapidement?

les numéros de "version" sont utilisés comme jalons pour les points de branchement, et non comme des versions majeures pour impressionner le public de la façon dont les autres développeurs les utilisent. Et c'est un flux de développement continu, avec des fonctionnalités prêtes ou non prêtes, plutôt qu'un événement occasionnel réunissant de nombreuses nouvelles fonctionnalités pour faire un grand événement

Blaireau paresseux
la source
7
L'OP a déclaré qu'il utilisait le versioning sémantique; pourquoi l'ignorez-vous alors?
Jörg W Mittag
-3

Lors de l'utilisation du contrôle de version sémantique, il reste à décider quels changements sont considérés comme "majeurs" et lesquels sont "mineurs". Il existe plusieurs raisons de bump le numéro de version - ou de ne pas le bump.

Les systèmes avec des promesses de compatibilité descendante pourraient finir par augmenter le numéro de version principal avec la plupart des mises à jour, simplement parce qu'il y a une rupture de compatibilité descendante dans certains cas d'angle plus ou moins ésotériques. Les mêmes systèmes pourraient rester presque indéfiniment dans 1.xy, car beaucoup d'efforts sont consacrés à la compatibilité descendante, en essayant de ne jamais casser aucun système dépendant. Les deux approches de la numérotation des versions pourraient être considérées comme «conservatrices», mais les deux pourraient également être le signe d'un profond problème sous-jacent.

D'autres fois, vous avez en fait un calendrier de sortie (pensez aux CD de mise à jour trimestriels envoyés aux clients) où il est logique de changer le numéro de version principal, de sorte qu'au lieu de "Version 3.4 / 16 octobre", il est simplement dit "Version 11.0". De nos jours, de plus en plus de logiciels sont publiés à de courts intervalles, ce qui rend les calendriers de publication moins une raison de s'en tenir à un schéma de version spécifique. J'ai vu cela dans les grands systèmes d'entrepôt qui n'autorisent l'informatique interne qu'un jour d'indisponibilité par trimestre (généralement un dimanche). Ce jour est le jour du déploiement et est marqué à chaque fois par une nouvelle version majeure.

Certains programmes ont des dépendances externes qui sont de la plus haute importance, car l'utilisateur devra mettre à jour les deux en même temps. Si vous disposez d'un module complémentaire Word qui ne fonctionne qu'avec Word 2010 et un autre pour Word 2013, vous souhaiterez peut-être synchroniser vos numéros de version principaux avec ceux de MS-Word. Ici, les nombres majeurs sont si importants, car certains de vos utilisateurs seront "derrière" votre calendrier de mise à jour normal, car ils n'ont pas mis à jour vers la version la plus récente de Word (ou quoi que ce soit sur lequel vous vous appuyez: SAP, Dynamics, etc).

Parfois, d' autres facteurs externes dictent les numéros de version. Si vous avez un logiciel fiscal, il peut y avoir des mises à jour annuelles correspondant à la loi fiscale (qui a tendance à entrer en vigueur le 1er janvier). De tels systèmes auront des versions majeures changeant exactement une fois par an - non pas parce que c'est le calendrier de mise à jour, mais parce que cela est d'une autre importance pour le client: Si vous faites vos taxes 2016, vous feriez mieux d'avoir un programme mis à jour selon la loi fiscale 2016.

En fin de compte, les numéros de version dépendent de tant de facteurs - souvent spécifiques à un domaine - que le numéro seul ne vous dit rien sur l'état de votre base de code. C'est une bien meilleure approche pour voir quand, pourquoi et comment les déploiements se produisent - et comment cela se passe sans heurts. Si vous pouvez déployer une mise à jour majeure auprès de 10 000 clients et passer quelques appels téléphoniques, tout va bien. Si vous déployez un correctif mineur pour 10 clients et devez faire des heures supplémentaires à cause de cela, quelque chose ne va probablement pas.

Hazzit
la source
3
"Lors de l'utilisation du contrôle de version sémantique, il reste à décider quels changements sont considérés comme" majeurs "et quels sont" mineurs "." - Non, il n'y en a pas; qui est précisément défini dans la spécification. "Il y a plusieurs raisons de bump le numéro de version - ou de ne pas le bump." - Non, il n'y en a pas; il y a précisément une raison d'augmenter le nombre majeur (dont traite cette question), et elle est définie précisément dans la spécification.
Jörg W Mittag
1
@ JörgWMittag Soit je me trompe, soit la spécification indique spécifiquement quand vous DEVEZ bousculer les numéros de version, mais elle ne dit rien sur le moment où vous POUVEZ.
Hazzit
-4

Le consensus sur la signification des numéros de version est en effet major.minor.revision.buildnumber

Si major monte rapidement, il se pourrait que le développeur ait toutes ces nouvelles idées et travaille très dur.

Cependant, dans le monde des affaires, il peut y avoir d'autres raisons d'augmenter le numéro de version principal. Comme

  • Les ventes sont en baisse, les clients / utilisateurs attendent la prochaine version majeure avant la mise à niveau.

  • Le contrat stipule que les clients ont droit à des mises à jour mineures. Le vendeur ne peut pas les facturer pour ceux-ci, donc une légère amélioration est vendue comme une mise à niveau majeure du produit.

  • Le concurrent X est dans le jeu depuis un peu plus longtemps, donc leur numéro de version principal se trouve être plus élevé que le vôtre. Cela donne l'impression que vous êtes en retard, vous devez "rattraper".

Martin Maat
la source
6
La question est étiquetée avec le versionnage sémantique , l'OP mentionne le versioning sémantique dans la question, et a réaffirmé dans les commentaires qu'ils utilisent le versioning sémantique. La spécification SemVer indique très clairement lorsque les versions majeures sont incrémentées. Aucune de vos "autres raisons" ne s'applique.
Jörg W Mittag