Release policy

LSC versions numbers contain 3 components: X.Y.Z.

1. An increment in Z is referred to as a minor update (example: 1.1.0 to 1.1.1).
2. An increment in Y is referred to as a major update (example: 1.1.1 to 1.2.0) which had new features but does not brake the ascending compatibility. It implies configuration modification to use the new XML schema.
3. An increment in X is referred to as a brand new version (ex 1.2.1 to 2.0) which implies a new design, gains many new features but requires a requalification of the deployed instances.

Minor updates are released regularly, in order to provide bugfixes. Exact schedules depend on the number of bugs fixed.

Full compatibility will always be offered between minor releases.

Major updates introduce new functionality. Schedules depend on when features are implemented, not on a specific date. The Roadmap offers more detailed information about these.

Backward-compatibility of major releases is generally available up to release Y-2. For example, migrating from 1.1.Z to 1.2.0 will be transparent. However, in version 1.3.Z may drop compatibility with some 1.1.Z features.

As the configuration file is in XML, and validated with an XSD file, switching to a new major release implies to update the XML namespace definition of all configuration files.

In all cases, any non backward-compatible changes will be documented in detail in the release notes.