Software version life cycles

Software versioning mode

The system versions of Stormshield Network Security appliances evolve over time. These changes may take place for 3 main reasons:

Due to a functional upgrade:

  • System update

  • Modification of existing features (feature enhancement)

  • Addition of new features (disruptive or incremental features)

    • Disruptive features drastically change the way the product is used, can have an impact on the previous behaviour of the product and can entail major modifications to the look&feel of the GUI.

    • Incremental features expand the functional scope with limited impact on the global behaviour of the product.

Due to a fix:

  • Security fix

  • Functional fix (Bug)

Due to hardware support:

  • Support of new appliances

  • Withdrawal of End-of-Life appliances

These updates are available for appliances under maintenance, running on a supported system version and which have valid subscriptions for the relevant optional services.

For Stormshield Network Security products, three types of system versions and one label are identified.

The system version numbers of Stormshield Network Security products are made up of three digits.

Major versions

These versions include disruptive features and may also include fixes, incremental features and feature enhancements. Disruptive features drastically change the way the product is used, can have an impact on the previous behaviour of the product and can entail major modifications to the look&feel of the GUI. A configuration change or a dedicated upgrade procedure may be required in order to update to such versions. Major versions can also be candidates for the removal of obsolete features.

Major versions are systematically named:

X.0.0 (for example 3.0.0)

  • The first digit identifies the major version

  • The next two digits are 0

Frequency of release for major versions = about every 12 to 18 months

A “major version branch” includes all the minor versions and corrective versions related to a major version.

For example, versions 3.0.1, 3.1.0 and 3.1.3 all belong to the v3 major version branch.

Minor versions

These versions essentially include feature enhancements and may also include incremental features and fixes. Minor versions can be candidates for the support of new hardware.

Minor versions are systematically named:

X.Y.0 (for example 3.1.0)

  • The second digit (more than 0) identifies the minor version

  • The last digit is 0

Frequency of release for minor versions = about every 4 months

For example, versions 3.1.0 and 3.3.0 are minor versions of the v3 major version branch.

Throughout their life cycle (set out in detail hereafter), versions, regardless of whether they are major or minor, may include fixes (functional or security).

Corrective versions

These versions include only vulnerability or functional fixes.

Corrective versions are systematically named:

X.Y.Z (for example 3.1.3)

  • The last digit (more than 0) identifies the corrective version

The frequency of release varies according to the need for fixes.

For example, versions 3.5.1 and 3.5.2 are corrective versions of minor version 3.5.

LTSB (Long-Term Support Branch) label

Versions tagged with this label can be major or minor versions and are considered as long-term stable versions. They are maintained for a minimum of 12 months. These versions are recommended for customers that prefer stability over new features and enhancements. They can be updated only with corrective versions.

LTSB versions are systematically named by appending the suffix LTSB to the version identifier:

X.Y.Z.LTSB (for example 3.1.0.LTSB)

  • The LTSB label identifies a long-term stable version maintained for a minimum period of 12 months, starting with “X.Y.0” release.

  • The overlap time between a new LTSB and the previous LTSB version is set for a minimum period of 6 months in order to help customers migrate to the new version.

  • During a LTSB lifetime, only vulnerability and functional fixes will be delivered through corrective versions.

Frequency of release varies according to the roadmap, granting a minimum of one LTSB version for each major version branch.

The listing of all active LSTB versions and their planned end-of-support dates can be found in this document. These planned dates can be postponed to a later date for support extension purposes.

Maintenance of versions

For each new major version X, the last minor version of the X-1 major version branch becomes the new LTSB version.

Pour each major version branch, only the LTSB versions and the last published minor version may be the target of future fixes or functional upgrades.

All active LTSB versions can receive fixes during their lifetime (no functional upgrades will be granted on these versions).

Example (fictitious versions numbers)

If the active LTSB versions of major branch v7 are 7.7.5.LTSB and 7.11.0.LTSB.

And if the last published version of major branch v8 is 8.0.3

Then these three versions will benefit from fixes:

  • Future fixes on major version branch v7 will be integrated into corrective versions 7.7.6.LTSB and 7.11.1.LTSB. Versions 7.7.5 and 7.11.0 will then no longer be supported.

  • Future fixes on major version branch v8 will be integrated into a corrective version 8.0.4 or a new minor version 8.1.0 in case of new functional upgrades Version 8.0.3 will then no longer be supported

For further information on version support by our Technical Assistance Center, please refer to the support charter available in your secure area