Releases

Lus releases are produced by a release engineering process, which divide 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 thoroughly tested, are still open to breaking changes, and may be unpredictable when used in production; you really shouldn’t use unstable builds in production, even if you really need a feature that is not yet in the stable build. However, for personal scripting or recreational programming, you can probably use the unstable build without any problems.

Stable releases

There is no timeline for stable releases, but they are typically released when all work-in-progress acquis have been completed and they received sufficient harness tests. Stable releases may be released with only a few days between them, or they take several months (or even years) to complete. It all depends on the completion of the acquis and the sufficiency of the harness tests.

The attribution of acquis to a release is dependent on when the acquis has been submitted. If, for example, version X.0.0 is being worked on, then any acquis submitted during this time will be slated for version X.1.0. There is no upper limit as to how many acquis can be submitted for a given release, but if there are too many, then they may be slated for a future release.

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 usually contain the latest features. For all intents and purposes, the term unstable is interchangeable with canary or nightly builds, especially as they are built on a continuous integration (CI) pipeline.

There is no guarantee that the unstable release will be useable, compatible with code targeting the stable release, or free of platform-specific oddities. It could be that it straight up does not work. Unstable releases are not as thoroughly tested as stable releases and shouldn’t be considered reliable, especially for production use. While unstable builds are subjected to the harness tests of their predecessor builds, and CI will not deliver artifacts if they fail, good performance on tests involving stabilized features does not mean that you should use the unstable build in production.

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, and a new unstable build has been released, 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, and also as an extra real-world test. If anything unexpected happens that isn’t already reported, you should report it so that it can be fixed.