Over the last several years, there have been many changes to both the customers that use our compilers and also to how they are obtained and utilized. The user base is more diverse with more broad market users and hobbyists. Migration between architectures (such as MSP430 to MSP432) has become more common. There is a greater need to quickly provide releases in conjunction with new architectural features. Finally, customers can download releases through the CCS App Center and are willing to more rapidly evaluate and adopt releases.
For these reasons, the compiler team adopted a new frequent release model for the MCU compilers (MSP430, C28x, and ARM) last year. In this release model, the MCU compilers have new releases every quarter. To avoid increasing our support costs, we introduced the concepts of Long Term Support (LTS) and Short Term Support (STS) releases. LTS releases adhere to the traditional support model of TI compilers:
* They are actively maintained for roughly two years.
* Production stop bugs are addressed within 2 weeks.
* Critical bugs are addressed within 60 days.
* Bug fixes are proactively applied to each active branch.
The STS release support model is very different:
* STS releases are only supported until the next release is available.
* Only production stop bugs will cause patch releases to be made.
* No planned patch releases.
* Bug fixes are not proactively applied to each branch.
The quality of STS releases is the same as LTS releases. STS releases go through the same validation process as our LTS releases and all exposed features are fully supported unless otherwise noted. As such, STS releases can be used in a production environment, but the user must do so understanding the support models. For many customers, it is a requirement that patch releases with only bug fixes are available in order to minimize the code changes. For these customers, LTS compilers are still required. However, they can still use STS releases during early development. Our belief is that broad market customers and hobbyists are much more willing to use the latest and greatest releases regardless of the support model.
With quarterly releases and two support models, the old compiler versioning scheme of ***major.minor.patch*** required rethinking. The version number should indicate important information about the release. In the old versioning scheme, the digits had the following definitions:
* The ***patch*** digit indicated that only bug fixes have been applied between two releases.
* The ***minor*** digit indicated that new features have been applied, but the releases are compatible.
* The ***major*** digit indicated new features with possible incompatibilities or major changes.
In practice, this system was somewhat flawed. It is actually very rare that incompatibilities are introduced and distinguishing between major and minor changes can be difficult. The new compiler versioning scheme is ***year.month.patch.`[LTS|STS]`***. The new scheme lets the user quickly determine the support model and date of a release. Major changes and incompatibilities will be communicated through release notes and CCS migration aids. The ***patch*** digit still has the same meaning. One major benefit of changing to this scheme is that every MCU compiler product has the same version number.
For more information, please see
[Compiler Version Numbers and What They Mean](https://processors.wiki.ti.com/index.php/Compiler_Version_Numbers_and_What_They_Mean)
Code Composer Studio will always be delivered with the latest LTS compiler. The STS compilers are available through the CCS App Center and Install New Software dialogs. The App Center will only show the latest available release. The graphic of the App Center will clearly indicate when the latest release is an STS support model.