Changement de numéro de version

Cette semaine nous publions une nouvelle version de toutes nos librairies et tous nos outils. Toutes ces nouvelles versions incrémentent la version mineure de l'application/librairie. Cela pourrait faire penser à une nouvelle fonctionnalité importante ou un fixe de sécurité, mais, en fait il s'agit d'un simple changement de numérotation pour contourner une limitation de Microsoft. On vous explique...



La numérotation des versions des applications/librairies Yoctopuce est composée de trois chiffres séparés d'un point. Par exemple 1.10.57762.

Le premier chiffre correspond à la version majeure et, comme son nom l'indique, correspond à un changement important et potentiellement non rétrocompatible de la librairie/application. Dans les faits, tous les changements de version majeurs que nous avons publiés étaient rétrocompatibles mais ajoutaient de nouvelles fonctionnalités (par exemple, TLS et IPv6).

Le deuxième chiffre correspond à la version mineure et correspond à des fixes 100% rétrocompatibles. Nous avons incrémenté ce chiffre une seule fois, il y a 10 ans, lorsque nous avions modifié notre protocole de communication USB. Nous avions décidé d'augmenter ce chiffre pour mettre en avant ce changement, mais c'était complètement invisible pour l'utilisateur.

Le dernier chiffre est le plus important, c'est le numéro de build. Ce numéro est un compteur monotone qui est incrémenté à chaque changement fait au code source. Il n'est jamais remis à zéro (enfin jusqu'à cette semaine) et nous permet de retrouver exactement le code source de l'application avec uniquement ce numéro.

En fait, les deux premiers chiffres ont une fonction cosmétique et de mise en avant de certaines fonctionnalités. Le dernier chiffre permet d'identifier de manière absolue la version du logiciel. Du reste, pour les firmwares de nos modules, nous n'indiquons que ce dernier chiffre. Ce qu'il faut retenir est que le troisième chiffre croit de manière indépendante des deux premiers.

Cette convention est compatible avec le standard Semver. Ce standard est très largement répandu et permet de gérer correctement les problèmes de dépendance et de compatibilité entre différentes versions d'une librairie. Ce standard est aussi utilisé dans de très nombreux package manager et dans les installeurs Windows.

Bref, nous avions un système pratique qui fonctionnait très bien jusqu'à la semaine passée.

Les plus attentifs aurons aussi remarqué que nos numéros de build s'approchaient de 65535 qui est le dernier chiffre représentable avec 16 bits. Et c'est justement ce qui nous a posé problème...

Microsoft et le 16 bits

Nous avons appliqué la même convention de numérotation dans nos projets Visual Studio et les installeurs Windows ainsi que pour nos librairies qui sont publiées sur nuget.

Le problème est que Microsoft a décidé de stocker chaque numéro dans un entier 16 bit, et donc de limiter la valeur maximum à 65535.

La limitation qui nous pose problème (cf documentation Microsoft):

Tous les composants de la version doivent être des entiers supérieurs ou égaux à 0. Les métadonnées limitent les composants principaux, mineurs, de build et de révision d’un assembly à une valeur maximale de UInt16.MaxValue - 1. Si un composant dépasse cette valeur, une erreur de compilation se produit.

Cette limitation pose problème pour les libraires C#, .Net Proxy et pour toutes nos applications (VirtualHub, Yocto-Visualization, etc).

Solutions

Nous avons donc dû changer notre convention de numérotation en faisant attention de ne pas casser tous les systèmes de mise à jour automatique des gestionnaires de package, comme NPM, NuGet, etc.

La solution que nous avons choisie est d'incrémenter le numéro mineur de tous nos packages et de soustraire 60000 au numéro de build.

Par exemple, la librairie C# est passée de la version v2.0.64286 à la v2.1.5971 et VirtualHub de v1.10.64951 à v1.11.5996.

Le numéro de version mineure correspondant à des modifications backward compatibles, les mises à jours des packages se feront automatiquement. Le fait que le troisième chiffre diminue ne pose pas de problème, car la version mineure est incrémentée.

Ce changement de numérotation sera donc perçu comme tout à fait normal et standard par tous les systèmes de package et autres installeurs. Seuls les humains qui ont l'habitude de nos numéros de version risquent d'être interrogés par ce changement.

1.10==1.11 et 2.0==2.1

Ce qu'il faut retenir est que le numéro de version mineure de toutes nos applications va s'incrémenter, mais que rien d'autre ne change. Il ne s'agit pas d'un changement de comportement, ou d'une nouvelle fonctionnalité que nous avons ajoutée. Vous pouvez sans problème passer de la version v1.10 à la v1.11 ou de la v2.0 à la v2.1.

Il y a toutefois un cas particulier: VirtualHub. Nous maintenons deux versions de VirtualHub. La version 1 qui est la version recommandée et la version 2 qui est pour l'instant encore en Beta. Ces deux versions ne sont pas identiques et n'ont pas exactement les mêmes fonctionnalités.

Ces deux versions vont continuer à exister en parallèle, mais vont avoir leur version mineure incrémentée. La version 1 va passer de 1.10 à v1.11 et la version 2 de 2.0 à v2.1.

Pour finir, voici les nouveaux numéros de version pour tous les packages: