> For the complete documentation index, see [llms.txt](https://docs.prismacloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prismacloud.io/content-collections/runtime-security/rs-support-lifecycle.md). # Runtime Security Support Lifecycle Because the container ecosystem is rapidly evolving, understanding supportability policies is an important part of keeping your environment supportable and secure. This article describes not only the support policy for Prisma Cloud itself but also for other software you may integrate it with. ## Definitions Major Releases (X.yy.zzz)\ A major release includes significant new features and changes and is typically released approximately every four months. It includes all applicable fixes made in previous releases. The numbering format indicates the subsequent major release. For example, `30.00` (for Maxwell), `31.00` (for the next), and `32.00` (for the one after). Maintenance Releases (x.YY.zzz)\ A maintenance release includes features, enhancements, and additional fixes; it is smaller in scale than a major release and incorporates all the applicable fixes made in previous maintenance releases. The numbering format of numbers starts with 00 (major release), 01 (minor 1), and 02 (minor 2). For example, Maxwell’s major release is `30.00.build`, the next maintenance release will be `30.01.build`, and maintenance update 2 will be `30.02.build`. End of Life (EOL)\ Versions that are no longer supported by Prisma Cloud. Updating to a later version is recommended. Support\ Includes not only resolution of technical issues through interactive assistance, but also fixes delivered in maintenance releases to correct problems. ## Prisma Cloud supported versions policy Prisma Cloud has an 'n-2' support policy, which means the current release ('n') and the previous two releases ('n-1' and 'n-2') receive support. Note that in some cases, the resolution of a problem in the n-1 or n-2 version may require upgrading to a current build. Prisma Cloud will make commercially reasonable efforts to work with customers that require porting fixes back to the n-1 or n-2 versions, but sometimes architectural changes are significant enough between versions that this is practically impossible without making the n-1 or n-2 versions essentially the same as the n version. There will be version-specific [API endpoints](https://pan.dev/compute/api/stable-endpoints/). With API versioning, as your Console is upgraded to newer versions, you can continue to use older versioned APIs with stability and migrate to newer version APIs at your convenience within the n-2 support lifecycle. As a best practice, update your scripts to use the version-specific API endpoints to ensure that your implementation is fully supported. For the version-specific APIs, you will have access to the [API Reference](https://pan.dev/compute/api/) and Release Notes documentation for changes or updates that may impact you. ## Third-party software Customers use a diverse set of technologies in the environments that Prisma Cloud Compute protects, including host operating systems, orchestrators, registries, and container runtimes. As the vendors and projects responsible for these technologies evolve, newly introduced versions and deprecated older versions can impact the scope of what Prisma Cloud supports. For example, Prisma Cloud cannot effectively support third-party software that the vendor (or project) itself no longer supports. Conversely, as new versions of 3rd party software are released, Prisma Cloud must comprehensively test them to be able to provide official support for them. For each major and maintenance release of Prisma Cloud Compute, we begin testing by evaluating the versions of 3rd party software we list as officially supported in our [system requirements](/content-collections/runtime-security/install/system-requirements.md). When new supported versions of this software are available, we perform our testing for the release using them. For example, if Red Hat were to release a new version of OpenShift before we begin testing an upcoming Prisma Cloud release, we’ll include that new OpenShift release in our testing. If the new version of OpenShift is released after we’ve begun our testing, we’ll instead do this validation in the subsequent Prisma Cloud release. Depending on where we are in the development cycle, this next release may be a maintenance release or the next major release. Typically, new 3rd party releases can be supported with no or minor changes in Prisma Cloud. However, there may be circumstances where a new version of 3rd party software introduces significant breaking changes that require more significant work within Prisma Cloud to maintain compatibility. In these cases, we’ll update the system requirements page to clearly note this and will communicate a roadmap for supporting this software in a later release of Prisma Cloud. While Prisma Cloud does not actively prevent interoperability with unsupported software, with each release we evaluate the versions of software supported by vendors and projects. As older versions are deprecated, Prisma Cloud support will similarly deprecate support for them as well. ## Upcoming support lifecycle changes for Prisma Cloud Compute Edition and modules As our customers' usage of containers and cloud native technology continues to mature, they often need longer product support lifecycles to accommodate enterprise class operational cadences. We’re announcing the following changes, effective in Prisma Cloud Compute "Iverson", which will ship in the second half of calendar year 2021: ### Extending support lifecycle to N-2 * Currently, the Compute support lifecycle is the current major version and the previous major version ("N-1"). * Beginning in Iverson, support will extend to the previous 2 major versions ("N-2"). * Given our \~4 month major release cadence, this is effectively a full year of support for any given major release. ### Defender <-> Console backwards compatibility * Defenders from any supported version will be able to connect to Consoles of the same or greater version. * This will be phased in, beginning with the Iverson release, which will support Defenders running either Iverson or Hamilton. * Joule Consoles will support Defenders running either Joule or Iverson or Hamilton. * twistcli and the Jenkins plugin will also provide this same backwards compatibility model. * Once a customer upgrades Defenders to Hamilton, they will not need to upgrade them again for 1 year, even as they upgrade their Consoles. ### Versioned API with guaranteed reliable endpoint behaviors * Currently, the Compute API is not versioned between releases, though there are a set of APIs which very rarely change documented in our [API stability guide](https://pan.dev/compute/api/stable-endpoints/). * Beginning in Iverson, each release of Console will include versioned API endpoints for the prior supported releases, with a guarantee that the included endpoint behaviors will remain constant for a given version. * Only APIs covered in the Stability Guide are included in these versioned endpoints; access to other APIs will not be actively prevented but they will be unsupported, undocumented, and may change at any time. * This will be phased in, beginning with the Iverson release, which will include a `/v-Iverson` endpoint as well as the existing `/v1` endpoint. * Joule will include a `/v-Joule` and a `/v-Iverson` endpoint, and the existing `/v1` endpoint; Kepler will include `/v-Kepler`, `/v-Joule`, and `/v-Iverson`. ### Removal of Defender auto-upgrade feature * Given lengthened supportability lifecycle and the introduction of Defender <-> Console version compatibility throughout it, customers will now have much longer times between required Defender upgrades (approximately only once per year). * Accordingly, to simplify upgrade flows and enable thorough testing of upgrade scenarios, Defender auto-upgrade will be removed from the product beginning in Iverson. * This change impacts both SaaS customers (Enterprise Edition) and self-host (Compute Edition) customers. * Customers that currently have auto-upgrade enabled will simply no longer have Defenders automatically upgraded after this change and no action is required on their part to decommission the feature. * Customers can take advantage of the wide variety of deployment and upgrade options already available in the product to upgrade Defenders at their own pace to keep them within the new N-2 support lifecycle. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.prismacloud.io/content-collections/runtime-security/rs-support-lifecycle.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.