--- description: > Explains CAP's yearly major, monthly minor, and patch release schedule, along with active, maintenance, and end-of-life status definitions. --- # CAP Release Schedule New **major versions** of CAP will be released **every 12 months**, in May 2024, 2025, 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. ![A kind of Gantt chart, showing the active and maintenance version of CAP](assets/schedule-overview.drawio.svg) ## Major Releases {#yearly-major-releases} ### CAP Node.js CAP releases are linked to the [Node.js Release Schedule](https://github.com/nodejs/release#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. ![A kind of Gantt chat, showing which CAP version supports which Node.js version.](assets/schedule-yearly-overview.drawio.svg) Example: CAP v9 - Was released in May 2025, when Node.js 18 reached end of life - Dropped support for Node 18, as that became out of maintenance - Supports Node 20 and Node 22 (Node 20 is now out of LTS maintenance) 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](https://cap.cloud.sap); 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 one or even 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](./index) 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](/@external/java/migration). A new major version might be driven by the release and maintenance schedule of crucial dependencies such as [Spring Boot](https://github.com/spring-projects/spring-boot/wiki/Supported-Versions) 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. :::tip New major versions are announced several months in advance You will find information [here](/@external/java/versions#dependencies) and in upcoming release notes. ::: Only the current major version has the [active status](#active). New (CAP) features are provided in this version only. Whereas the previous major version has [maintenance status](#maintenance-status). This version will be maintained for a period of time appropriate for migrations. ::: tip Stay updated Active CAP-based projects are strongly encouraged to adopt new major versions as soon as possible, as **a version in maintenance status will receive critical bug fixes only**. ::: ## Monthly Minor Releases {#minor} Releases in [active status](#active) 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](./index). 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](#patch) or minor version updates of individual CAP packages to *[npmjs.com](https://www.npmjs.com)* or to *[Maven](https://search.maven.org)*. ## Patch Releases {#patch} 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 { #active } New major releases enter *active* status on date of release. Active releases are updated with [monthly minor releases](#minor) 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](#patch) in case of urgent hot fixes. Only the latest minor release of the active version receives patches. ::: tip Stay updated CAP-based projects are strongly encouraged to adopt the [latest minor release of the active version as soon as possible](#adoption-strategy) during their development cycles to benefit from these updates. ::: ## 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](#end-of-life-status). 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](#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.