Release policy
This document outlines the release policy for StreamX, detailing how versioning, module releases, and documentation are managed for both public and internal releases. This policy is designed to ensure a consistent and organized release cycle that aligns with the needs of development, client deployment, and public transparency.
Release semantics
The StreamX projects follow a modified Semantic Versioning system with LTS.feature.development.
Release types
-
LTS releases (e.g., 1.0.0, 2.0.0): These are long-term support versions. An increase in the
LTSversion number signals a new long-term support release rather than indicating major feature changes or breaking updates. -
Feature releases (e.g., X.1.0, X.2.0): New features are introduced with an increment in the
featureversion number. -
Development releases (e.g., X.X.1, X.X.2): These releases are part of the standard development cycle and are used by the StreamX development team for ongoing updates and improvements.
On-demand changes
Urgent patches for clients will be delivered with suffixes to the standard version.
For example, if an urgent fix is required for version 1.2.0, the release version might be 1.2.0-patch001.
Examples
To clarify the release structure further, here are some examples:
-
1.0.0– An LTS release. This is a stable, long-term support version. -
1.1.0– A feature release after the 1.0.0 LTS. -
1.1.2– A development release after 1.1.0 for ongoing updates and improvements, before the next feature release. -
1.2.0– Another feature release introducing additional functionality. -
1.2.3– A development release after 1.2.0 for ongoing updates and improvements, before the next feature release. -
1.1.0-patch001– An on-demand change for version 1.1.0, released to address a specific client issue urgently. -
2.0.0– The next LTS release, marking a stable version for long-term support.