Version Number Schema
The Netint Quadra release package contains multiple components, each with their own release version numbers and semantic-like compatibility numbering.
Release Version Numbering
The NETINT Quadra release version numbers (eg. 5.8.0) consist of 3 single characters:
Major.Minor.Micro
Major milestone releases will increment the Major character. These major releases support large new features and new capabilities. As the product matures, Major releases become less frequent.
Minor releases are built upon a major release branch and are far more frequent. These are normally periodic releases, with a cadence of every 3 months or so. New features are added for these Minor releases and they will always contain the latest bug fixes available. Each new Minor release increments the Minor version number/character.
All other types of releases increment the micro number. These releases are normally specifically for customers, and will contain specific fixes for specific problems, they may also contain changes in behaviour that does not affect the default settings of the device.
The release version number characters may be 0-9 and A-Z.
Example : 5.9.A, 2.A.A, 4.8.R
Component Versioning (Firmware and Software)
NETINT release packages have a release version number, and the FW and SW components inside the release package also have their own, 3 character FW/SW release version number.
FW and SW releases in a release package do not always share the same release version number. If FW and SW releases in a release package are of different release version numbers, the release package's release version number will be the largest release version number between the FW and SW’s release numbers.
Version Supersedence
A release with a greater release version number supersedes the releases with lesser release version numbers. Newer releases are built/based upon older releases. It is preferable that the user uses the release with the greatest release version number to give them access to the latest features and fixes.
Release Candidate Version
The Release Candidate version is a single character after the main version and they represent new internal release packages (or components) when we are release testing. This is just an internal version for use at NETINT as there is only one officially released Release Candidate per release version. So for example version 5.8.0 may contain Release Candidate A of the firmware and Release Candidate 6 of the software.
Backward Compatibility
The upgrade strategy for a customer is built around the version numbering. To start with, customers will experiment and integrate with the latest release versions. They often request new changes and fixes, and these are provided in new releases.
As their application code hardens, and solutions have been tested and proven, they accept fewer changes, in order to increase stability and predictability.
The device, firmware and host installed software are all backwardly compatible between releases. This means the user does not need to migrate their application code in order to change between 2 release versions, even major versions. However if the customer has requested changes that are only enacted with new parameters or parameter values, then the customer will need to change their application code to enable their new requested features or behaviour.
When NETINT publishes a new API the existing APIs remain identical in terms of function signatures (function names, arguments, return types etc), internal structures (these are also versioned), and the devices behaviour. At NETINT we always try to reduce friction for customers by making sure the customer experiences no drop in performance or quality, and sees no change in behaviour, when upgrading to a new release. The only exceptions to this are if we have made device improvements in performance/quality/power, or have fixed incorrect behaviour in the device i.e. bug fixes.
Moving to Production
As customers move more to their production environment and integration is completed, they may wish to limit the code changes they receive from an upgrade. This often requires the customer to only accept hotfixes for specific issues, and only upgrade to new micro release versions.