Releases

Lus releases are produced by a release engineering process that divides into two channels:

• The stable channel, which is well-tested and ready for production use.
• The unstable channel, which contains the latest features.

Unstable does not necessarily mean that they are literally unstable, but rather that they have not been sufficiently tested and are still open to breaking changes.

Stable releases

There is no timeline for stable releases, but they are typically released when all work-in-progress acquis have been completed and have received sufficient coverage in the test harnesses.

The attribution of acquis to a release is dependent on when the acquis is submitted. If the version X.0.0 release is being worked on, then any acquis submitted during this time will be slated for version X.1.0.

Even though semantic versioning is used, the patch number is expected to go unused. The harness tests are exhaustive and should cover all runtime features and edge cases. If, however, a very critical bug is found, then the patch number may be used to indicate an emergency bug fix release.

Developers should use the stable release of Lus for production use.

Unstable releases

Unstable releases are released more frequently than stable releases and contain the latest features. For all intents and purposes, the term unstable is interchangeable with canary or nightly builds.

There is no guarantee that the unstable release will be useable, compatible with code targeting the stable release, or free of platform-specific oddities. Unstable releases are not as thoroughly tested as stable releases and shouldn’t be considered for production use.

That said, the use of unstable builds in a testing capacity is encouraged. If you are working on a program that already makes use of Lus, you should use the unstable build to test your program against the latest features and bug fixes to see if any breaking changes have been introduced.