Recherche des meilleures pratiques pour la numérotation des versions des composants logiciels dépendants

Nous essayons de décider d'une bonne façon de numéroter les versions des composants logiciels, qui dépendent les uns des autres.

Soyons plus précis:

Le composant logiciel A est un micrologiciel exécuté sur un périphérique intégré et le composant B est son pilote respectif pour un PC normal (machine Linux / Windows). Ils communiquent entre eux à l'aide d'un protocole personnalisé. Étant donné que notre produit est également destiné aux développeurs, nous proposerons des versions stables et instables (expérimentales) des deux composants (le micrologiciel est de source fermée, tandis que le pilote est de source ouverte). Notre plus grande difficulté est de savoir comment gérer les changements d'API dans le protocole de communication.

Pendant que nous implémentions une vérification de compatibilité dans le pilote - il vérifie si la version du micrologiciel est compatible avec la version du pilote - nous avons commencé à discuter de plusieurs façons de numéroter les versions.

Nous avons trouvé une solution, mais nous avons également eu envie de réinventer la roue. C'est pourquoi j'aimerais obtenir des commentaires de la communauté des programmeurs / développeurs de logiciels, car nous pensons que c'est un problème courant.

Voici donc notre solution:

Nous prévoyons de suivre la numérotation des versions major.minor.patch largement utilisée et d'utiliser des nombres mineurs pairs / impairs pour les versions stables / instables. Si nous introduisons des modifications dans l'API, nous augmenterons le nombre mineur.

Cette convention conduira à l'exemple de situation suivant:

La branche stable actuelle est 1.2.1 et instable est 1.3.7. Maintenant, un nouveau correctif pour instable modifie l'API, ce qui fera que le nouveau numéro de version instable deviendra 1.5.0. Une fois que la branche instable est considérée comme stable, disons en 1.5.3, nous la publierons en 1.4.0.

Je serais heureux d'une réponse à l'une des questions connexes ci-dessous:

• Pouvez-vous suggérer une meilleure pratique pour gérer les problèmes décrits ci-dessus?
• Pensez-vous que notre convention "personnalisée" est bonne?
• Quels changements appliqueriez-vous à la convention décrite?

Les numéros de version à mon humble avis sont comme les noms de produits; important en ce qu'ils sont visibles mais sans importance en ce qu'ils sont la décoration plutôt que le contenu.

Pourtant, le numéro de version, comme un nom de produit, a un sens. Et la chose la plus importante que vous puissiez faire est d'éviter toute confusion. Voici donc quelques attentes courantes en ce qui concerne les numéros de version. Dans la mesure où ces exceptions ne sont pas respectées, l'utilisateur sera probablement confus:

Le nombre de versions augmente de façon monotone
C'est probablement l'attente la plus évidente, et en même temps la moins susceptible d'être vraie. En un coup d'œil, l'utilisateur s'attend à ce que la version 2.3.5 vienne après la version 2.2.17 et dispose de la même technologie ou d'une technologie meilleure. Mais bien sûr, 2.3.x est une branche de développement , et 2.2.x est stable , et 2.3.5 a en fait été publié en 2004 et la branche 2.2 est toujours activement travaillée et 2.2.17 a été publiée en avril dernier et contient. .. eh bien, vous avez l'idée. Vous pourriez tout aussi bien appeler la version 2.2 "Potato" pour toute la signification du numéro. Bienvenue dans la version " Potato-17 " !!

Des versions similaires sont évolutives / compatibles.Si
j'ai la version 3.7 sur mon ordinateur et que la 3.8 sort avec tous les nouveaux frozbots brillants, je m'attends à ce qu'avec une mise à niveau ou un correctif ou autre, mon 3.7 puisse devenir 3.8 sans interruption. Mais si je suis sur 3.7 et que vous publiez 5.2, je ne suis pas aussi optimiste. Bien sûr, je préfère être agréablement surpris plutôt que déçu.

Le premier chiffre est significatif,
je ne prendrais même pas la peine de le mentionner si Java n'était pas aussi déroutant en la matière. À moins que quelqu'un ne vous le dise, vous ne vous attendriez pas à ce que "Java 7" soit en fait la version 1.7. Et la première fois que vous avez entendu cela, votre réponse a été presque certainement: " Quoi? .. Pourquoi? "

Clairement, le puriste dira que le numéro de version majeur ne changera que si le changement de plate-forme n'est pas rétrocompatible. Mais avez - vous réellement l' intention d'abandonner la rétrocompatibilité jamais ? Souvent, les tours de version majeurs sont une décision marketing et non technique; l'absurdité Java vient du fait que les deux camps ont leur chemin en même temps, pour un effet presque comique.

Enfin
Comme je viens de le mentionner, les numéros de version concernent souvent autant le marketing que la technologie. Et c'est OK, car c'est à peu près à cela que servent les numéros de version: vous informer en un coup d'œil des nouveautés du logiciel. Un grand changement de nombre signifie un grand changement de fonctionnalité. Le changement de petit nombre signifie presque aucun changement de fonctionnalité. Voilà ce que les gens attendent . Que ce soit vrai ou non détermine si vos numéros de version ont la même signification que vos utilisateurs pensent qu'ils le font.

- EDIT -
J'ai oublié de le mentionner, mais Caleb l'a bien souligné: n'utilisez pas les numéros de version pour indiquer quelque chose d'important (par exemple stable / instable) sans le rendre explicite ailleurs ailleurs. Oui, vous savez que le numéro de version mineure impair indique un développement, mais cela fait de nous l'un d'eux. Le surnom de version «instable» de Debian est un bon exemple; ou vous pouvez également utiliser un nom de produit totalement distinct; "Frozbot 1.2" pour le nom de votre produit et "Devbot 1.3" pour votre version de développement.

Une fois que la branche instable est considérée comme stable, disons en 1.5.3, nous la publierons en 1.4.0.

Non non. Pour instable 1.5.3 stable doit commencer à partir de 1.6.0 (et 1.4.x vient de manquer, si vous souhaitez utiliser le versionnage sémantique)

Vous essayez d'utiliser une valeur pour indiquer deux choses distinctes.

Tout d'abord, vous avez une "version", qui sert généralement à identifier les différentes versions et à indiquer l'ordre dans lequel les versions ont été effectuées. Comme l'a dit tylerl, la version devrait toujours augmenter - cela n'aurait aucun sens pour les utilisateurs (et cela pourrait aussi causer beaucoup de confusion interne) si vous changez la version de 1.5.3 en 1.4.0.

Deuxièmement, vous essayez d'indiquer si une version donnée est stable ou non.

Il est possible d'indiquer les deux choses avec un seul "numéro de version", tout comme certains magasins utiliseront un système de tarification pour indiquer si un article est en vente. Par exemple, les prix qui se terminent par «3» dans un magasin près de chez moi sont des prix de vente finaux. Cela fonctionne bien pour les employés, qui apprennent rapidement à repérer un prix de vente, mais ce n'est pas un excellent moyen de parler de la vente à vos clients. Pour cette raison, ils ont également mis des panneaux près des articles en vente. Vous pouvez faire quelque chose de similaire, comme égaliser le chiffre le moins significatif pour les versions stables et le rendre impair pour les versions expérimentales. Je pense, cependant, que si vous sortez quelque chose qui est expérimental, vous devez clairement le marquer de cette façon. Vous pouvez ajouter un «X» au début ou à la fin de la chaîne de version, comme:X.1.5.31.5.3.X. Vous pouvez même un numéro de version expérimentale après cela, vous pouvez donc publier plusieurs versions expérimentales toutes basées sur la même version de base: 1.5.3.X1, 1.5.3.X2.

Vous devriez également considérer qu'il ya une longue tradition d'utilisation « alpha » et les numéros de version « bêta » pour indiquer les versions qui ne peuvent être stables ou complète: 1.5.3a54. Assurez-vous d'avoir une bonne raison de s'écarter de ce schéma si vous décidez de faire autre chose, car vous devrez probablement expliquer autre chose à votre communauté de développeurs.

Je suggérerais d'utiliser le format major.minor.patch, en utilisant une extension "tag" pour les versions stables / instables, et une signification précise des nombres majeurs et mineurs:

major.minor.patch-stable|unstable

où

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

De cette façon, les dépendances sont facilement gérées et indiquent à chaque client / utilisateur de composant quand ils doivent prêter plus d'attention aux nouvelles versions. Par exemple, si le composant A (1.1.0-stable) dépend de B (5.4.534-stable) et qu'une nouvelle version de B est attendue (6.1.0-unstable), on est immédiatement conscient que A devra être modifié, éventuellement considérablement .

J'aime vraiment la façon dont Hibernating Rhinos a construit des versions RavenDb vis-à-vis - elles ont juste un nombre de construction toujours croissant. Quand ils en ont un stable, il devient stable. Mais tout est un candidat à la sortie.