CAP Release Schedule ​

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.

Major Releases ​

CAP Node.js ​

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 ​

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.

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.

Monthly Minor Releases ​

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.

In between official releases, we publish new patch versions or minor version updates of individual CAP packages to npmjs.com or to Maven.

Patch Releases ​

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.

Active Release Status ​

New major releases enter active status on date of release.

Active releases are updated with monthly minor releases to receive the following:

• New CAP features
• Support for new versions of platform services, including databases
• Support for new major versions of Node.js and Java
• Support for new major versions of 3rd party libraries
• All kinds of minor fixes

They are updated with a patch release in case of urgent hot fixes. Only the latest minor release of the active version receives patches.

Maintenance Status ​

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.

End of Life Status ​

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.

Adoption Strategy ​

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.