Change of version number

This week we're releasing new versions of all our libraries and tools. All these new versions increment the minor version of the application/library. This might sound like an important new feature or security fix, but in fact it's a simple numbering change to get around a Microsoft limitation. Here is why ...




Yoctopuce application/library version numbering consists of three digits separated by a dot. For example, 1.10.57762.

The first number corresponds to the major version and, as the name suggests, to a major and potentially non-backward-compatible change to the library/application. In fact, all the major version changes we've published have been backward-compatible, but have added new features (e.g. TLS and IPv6).

The second number corresponds to the minor version and to 100% backward-compatible fixes. We incremented this number only once, 10 years ago, when we modified our USB communication protocol. We decided to increase this number to highlight the change, but it was completely invisible to the user.

The last number is the most important one : the build number. This number is a monotonous counter that is incremented with each change made to the source code. It is never reset to zero (well, until this week) and allows us to find the exact source code of the application with just this number.

In fact, the first two digits have a cosmetic function, highlighting some features. The last digit identifies the software version. Incidentally, for the firmware of our modules, we only indicate this last number. The important thing to remember is that the third digit grows independently of the first two.

This convention is compatible with the Semver standard. This standard is very widely used and enables us to correctly manage dependency and compatibility problems between different versions of a library. This standard is also used in many package managers and Windows installers.

In short, we had a practical system that worked very well until last week.

Those paying close attention may also have noticed that our build numbers were approaching 65535, which is the last number that can be represented with 16 bits. And that's precisely where the problem comes from...

Microsoft and 16 bits

We have applied the same numbering convention in our Visual Studio projects and Windows installers, as well as for our libraries published on nuget.

The problem is that Microsoft has decided to store each number as a 16-bit integer, limiting the maximum value to 65535.

This is the limitation that's causing us problems (see Microsoft documentation):

All components of the version must be integers greater than or equal to 0. Metadata restricts the major, minor, build, and revision components for an assembly to a maximum value of UInt16.MaxValue - 1. If a component exceeds this value, a compilation error occurs.

This limitation poses a problem for C# libraries, .Net Proxy and all our applications (VirtualHub, Yocto-Visualization, and so on).

Solutions

We therefore had to change our numbering convention, taking care not to break all the automatic update systems of package managers such as NPM, NuGet, and so on.

The solution we chose was to increment the minor number of all our packages and subtract 60000 from the build number.

For example, the C# library went from version v2.0.64286 to v2.1.XXX and VirtualHub from v1.10.64951 to v1.11.XXX.

The minor version number corresponds to compatible backward modifications, so package updates will be performed automatically. The fact that the third digit decreases is not a problem, as the minor version is incremented.

This change in numbering will therefore be perceived as completely normal and standard by all package systems and other installers. Only humans who are used to our version numbers are likely to be questioned by this modification.

1.10==1.11 and 2.0==2.1

The important thing to remember is that the minor version number of all our applications will increment, but nothing else changes. It's not a change in behavior, or a new feature we've added. You can easily go from v1.10 to v1.11 or from v2.0 to v2.1.

There is, however, one special case: VirtualHub. We maintain two versions of VirtualHub. Version 1, which is the recommended version, and version 2, which is currently still in Beta. These two versions are not identical and do not have exactly the same functionalities.

These two versions will continue to exist in parallel, but will have their minor versions incremented. Version 1 will go from 1.10 to v1.11 and version 2 from 2.0 to v2.1.

Finally, here are the new version numbers for all packages: