New major versions of CAP will be released every 12 months, in May 2023, 2024, and so forth. Active CAP-based projects are strongly recommended to adopt new majors as soon as possible, as former releases will receive critical bug fixes only. This schedule gives a reliable basis for planning adoption accordingly.
CAP releases are linked to the Node.js Release Schedule: New major releases are triggered by end of life of Node.js LTS releases, as depicted in the following figure. Active releases always only support the two Active and Maintenance LTS versions of Node.js.
Example: CAP v5
Was released in April 2021, when Node.js 10 reached end of life
Dropped support for Node 10, as that became out of maintenance
Supports Node 12 and Node 14
Major version upgrades may incorporate breaking changes to public APIs, yet we will avoid that as much as possible. Public APIs are explicitly documented in public and official docs only – that is capire; excluding tutorials, sample code, blogs, or similar.
Individual components of CAP can have independent major, minor, and patch version numbers. Yet, all major version upgrades will be synchronized to the yearly major version upgrades of CAP overall, without intermediate major version upgrades of individual components in between.
CAP Java major versions are usually developed and offered over a period of several years. In general, public APIs are kept compatible within a major version. Incompatible changes are only done if unavoidable and are documented in release notes accordingly.
A new major version may introduce incompatible changes to APIs or may adjust behavior of APIs. Such changes are done for good reason only and are documented in a migration guide.
A new major version might be driven by the release and maintenance schedule of crucial dependencies such as Spring Boot or if the minimum JDK version needs to be increased. Hence, there is no fixed schedule of major releases. For instance, CAP Java 2.0 has been introduced to support Spring Boot 3 on basis of JDK 17.
New major versions are announced 6 months in advance, here and in the release notes.
→ No new major release planned yet.
Only the current major version has the active status. New (CAP) features are provided in this version only. Whereas the previous major version (currently 1.34) has maintenance status (LTS). The LTS version will be maintained for a period of time appropriate for migrations. Planned end of maintenance of current LTS version 1.34 is April 24. But note that Spring Boot 2.7 is end of maintenance November 23 already.
Active CAP-based projects are strongly encouraged to adopt new major versions as soon as possible, as a version in maintenance status (LTS) will receive critical bug fixes only.
Releases in active status are equal to the latest development branches of CAP components, hence receiving ongoing feature development. Such new features are published in monthly minor releases, with accompanying release notes.
Minor version upgrades come without breaking changes to public APIs. They may incorporate breaking changes to undocumented, hence private interfaces though, which should never be used in projects using CAP.
A patch release of a minor release receives critical bug fixes only. It could also include code for new features, which are not considered public until officially released with according documentation. Such features will not be active by default.
Whenever a new major CAP version is released, the former major version enters maintenance status. It receives critical bug fixes only and for a period of at most twelve more months. After this, it reaches end of life.
A release in maintenance status does not receive the following:
Updates with new features at all
Support for new versions of platform services or databases
Support for new versions of Node.js and Java
Fixes for minor bugs and gaps
Support for new (major) versions of 3rd party libraries
In essence, critical bugs are security incidents, and bugs showing up in customer usages of already developed and shipped applications. Gaps and bugs detected in new developments with functional enhancements are not considered critical bugs.
After at most twelve months in maintenance status former releases reach end of life. They don't receive any fixes at all from that point on – all bug reports are rejected by default. Projects sticking to end of life versions of CAP must ensure to also stick to non-changing environments, that means:
Freeze on Node.js, Spring Boot or Java versions, only patch updates allowed
No updates of platform services or databases beyond hotfixes
No updates of 3rd party libraries beyond patch versions
No new development beyond hotfixes
In essence, projects sticking to end of life releases of CAP can continue to run 'as is', but should not be touched beyond hotfixes and cosmetic changes.
As stated already, projects using CAP are recommended to upgrade to latest minor release of the active version as soon as possible.
Assumed a project is planned to have a big go-live release R1 to customers (RTC) in May 2022, the project's dev schedule might look like that:
Current development for R1 is on CAP v5
Dev close for R1 in March/April 2022 → intensive testing
Start of R1.1 dev cycle in parallel on CAP v6
Release of R1 in May 2022 on CAP v5
Main development for R1.1 on CAP v6
Release of R1.1 in September 2022 on CAP v6
In general, upgrading as soon as possible doesn't mean that deployed applications need to upgrade, they continue to run with latest frozen versions, of course. Also near-term go-lives should not be endangered by adopting new major versions. But all forward-looking development should happen on active releases only.