Trustbuilder Software Version Guidelines

Trustbuilder applies the following naming convention for its software version numbering. As an example: IDHub-9.3.2

The name of the software build is followed by its version number. It consists of 3 digits:

  • First digit: Major Version
  • Second digit: Minor Version
  • Third digit: Maintenance Version

Sometimes the version is suffixed by an "-RC1" or a "-SNAPSHOT"

When it's suffixed by SNAPSHOT, this means it's an untagged development build. This version may not be used in any environment, except in development environments in extreme cases.  These versions can generally contain unfinished features.  Based on the file name, we cannot retrieve which instance of the source code is being used, which makes troubleshooting much harder.

When it is suffixed by "-RC1" or any subsequent number (RC2, ...), this implies it's a Release Candidate. This is a beta release version that is made selectively available.  This version can be used in development and acceptance environments to beta test a new Trustbuilder release.  However, as soon as a production (without any of these suffixes) release has been made available, this should replace the Release Candidate.

Difference in Versions

Note: the information below applies strictly from IDHub 9.2 onwards.  Because of non-conventional practices used before this release, the following guidelines don't always apply to version 9.1 and earlier.  Please refer to the release notes for each version for more information.

The guidelines below are only guidelines.  We highly recommend customers to apply their own deployment and testing procedures. There is always a risk something goes wrong with an upgrade, and every upgrade should get an appropriate amount of time in test. 

Maintenance version

Maintenance releases are small, incremental updates of the software.

  • The focus of maintenance releases is to fix bugs and to address vulnerabilities.
  • There are no major functional changes.
  • There are no database updates.
  • In rare cases, small functional improvements can be included.

It is highly recommended to keep your environments updated to the latest maintenance release.

Upgrading a maintenance version can be done by editing and running the environment.yml playbook, followed by sudo yum update 'trustbuilder-*'

Minor version

Minor updates are larger upgrades of the software that introduce new features and major improvements.

  • Adds new features and may extend behavior of existing features.
  • Maintains backwards compatibility between feature.
  • Includes database updates. 
  • May require configuration updates, but this is avoided as much as possible.

An update to a new minor version should be considered if it contains functionality that you want to use.  

Upgrading a minor version is always done by running the entire Ansible playbook.  Take note of any special installation or upgrade procedures added in the release notes.

Major version

These releases represent major evolutions in the software, and will generally have larger new features added, with architectural changes.  These are high impact upgrades that need to be analyzed, planned and tested in depth before deploying.

  • Architecture may change, requiring to change the appliance landscape correspondingly.
  • Database changes are expected, and may in some cases even require some data migration.
  • Configuration changes are expected, backwards compatibility is not guaranteed.
  • New functionality may render features from previous major versions obsolete.

Upgrading to a new major version is best done by installing it in parallel to the current appliance, and once it's stable to do a complete switch-over.

Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.