Before discussing the KOS release process, it’s important to understand what a KOS release represents. KOS consists of many components and a release represents a collection of these components that are guaranteed to work together and identified by a unique release number. Individual components within a KOS release have their own version numbers which may have no relation to the KOS release version. In fact, it’s entirely possible for some components to be identical between two different releases of KOS.
The proper way to think of a KOS release is that it represents a bill of materials (BOM) for a particular collection of components that is tested and supported. This also drastically simplifies development within KOS as a KOS release is always accompanied by a similar BOM for the corresponding SDK’s. This avoids the need for developers to track versions of individual SDK’s during development.
It’s also important to understand that a KOS release number conveys very little information about compatibility. Each release is a three digit number with the following meaning:
- First digit: Generally represents the generation of KOS. This number is incremented when major changes to the whole of KOS are made. These are generally very rare.
- Second digit: A number that is incremented for each new release. For any two releases that share the same first digit, the higher second digit represents a newer release.
- Third digit: Patch number for a given release. Every release starts at zero and increments as patches are released. Releases that differ only by patch version are considered to be highly compatible and differ only in bug fixes.
As a KOS release encapsulates so much functionality, it’s not possible to represent compatibility with a single version number. Instead, KOS relies on api version numbers to convey compatibility. KOS SDK’s document the api version when a service or component was introduced as well as the version when it was last changed. Each api is tagged with the api version it was introduced in. This allows developers to review their api usage against the api version documentation to determine compatibility with various KOS releases. This makes it easy to determine forward compatibility but also to audit how far back a given api is compatible with in previous KOS releases.
Preview Releases
Every KOS release starts as a preview release, often referred to as a dot-X release as the last digit of the release is the letter ‘x’. The purpose of a preview release is to share upcoming changes with the community as early as possible to expose new functionality and receive feedback. This is a powerful mechanism for partners to influence how features evolve in KOS.
A preview release is created shortly after any public KOS release and is periodically updated when features and changes are considered relatively stable. As preview releases change over time, they can be unstable or result in breaking changes. These releases are intended for early access and testing and are not intended for production use. As preview releases change over time, the corresponding SDK’s are not available in public repositories and are only available on KOS hosted repositories.
As a KOS release progresses towards a public release, preview releases will tend to be updated more frequently with final changes and documentatin.
Public Releases
When a preview release is finally complete, a public release is generated where the ‘.x’ is replaced by ‘.0’. The public release is then published to KOS Studio and becomes available for use by the community. All SDK’s are published to public repositories using the version number of the public release, ensuring that users simply need to match their SDK version to their selected KOS version to get access to the correct SDK’s for development.
During the support window for the public release, any patches applied to the release will increment the final digit of the public release version number. Each patch is treated as a public release and includes an updated set of SDK’s pushed to public repositories.
Public releases are indented for production use. Not only as the base operating system on a device, but also as the target of applications in the market.
Daily and Weekly Releases
In addition preview releases, KOS is also available in the form of a daily or weekly release. These are releases are restricted but can be accessed upon request. Daily releases are built in real time as changes are committed by the the core KOS development team. Access to the daily release is typically provided for debugging issues that cannot be reproduced by the KOS core team as it allows near real time collaboration with the community.
While daily releases delivery the absolute latest changes in KOS, they can be quite unstable as api’s change and testing is incomplete. Weekly releases are built every Sunday and represent a balance between the constant changes in daily and the relatively slow updates to a dot-X release.
By convention, all KOS versions with a first digit of 0 represent a daily / weekly release. For example, all java SDK’s for daily have a version of 0.0.0-SNAPSHOT.
Non-KOS projects
The KOS team provides access to a broad range of non-core components, ranging from tutorials, sample applications, and so on. These components are generally updated for public releases and released in conjunction with a dot-0 release of KOS.