[OPTMZT-89]: Update image policies for 2025

Author: brentmmarks

jekyll/_cci2/android-images-support-policy.adoc

@@ -18,11 +18,11 @@ This document outlines the CircleCI Android image release, update, and deprecati
 [#release-policy]
 == Release policy
 
-Android images are released once a quarter, with patch releases potentially being made for security issues. These images are generally built on top of the latest version of our most recent stable base Ubuntu image with added packages for Android.
+Android images are released once a quarter, with patch releases potentially made for security issues. These images are generally built on top of the latest version of our most recent stable base Ubuntu image with added packages for Android.
 
 - We install the most up-to-date versions of each tool/package in newly built images.
 - We aim to package 6 levels of the Android API within each image release.
-- As this image is not specifically designed for the Android Gradle Plugin (AGP), some updates may come later than desired. However, we aim to follow compatibility matrices for link:https://docs.gradle.org/current/userguide/compatibility.html[AGP] and link:https://developer.android.com/build/releases/gradle-plugin#updating-gradle[Gradle].
+- As this image is not specifically designed for the Android Gradle Plugin (AGP), some updates may come later than desired. We aim to follow compatibility matrices for link:https://docs.gradle.org/current/userguide/compatibility.html[AGP] and link:https://developer.android.com/build/releases/gradle-plugin#updating-gradle[Gradle].
 
 Releases may be skipped if there are no material updates to core Android functionality, such as `sdkmanager`, `ndk` or platform versions.
 
@@ -37,12 +37,10 @@ For the latest major version of Docker:
 
 - `edge`: These tags are reserved for previews of new releases, which will initially point to this tag. The `edge` tags may include incremental updates to the `current` image release, which may change without notice, and is not recommended to be used for production CI workloads. `current` will be updated with these changes after a period of stability (generally an average of a week).
 
-- Date based tagging: Android images are generally released once every 3 months. The date-based tagging conventions take the format of `<year>.<month>.<patch>`, such as `2023.10.1`. We recommend using the `default` version and not pinning to a date version.
-
 [#critical-cve-patches]
 == Critical CVE patches
 
-When critical CVEs are disclosed that affect the versions of the operating system or software stack in our Docker convenience images, we will investigate the impact that this has on our images being used within the CircleCI execution environment. If customers are impacted by these CVEs we will push a patch fix to the released image(s), and this image will supersede the original image.
+When critical CVEs are disclosed around the operating system or software stack of this image, we will investigate the impact this has on the image within the CircleCI execution environment. If customers are impacted by these CVEs we will push a patch fix to the released image(s), and this image will supersede the original image.
 
 [#bug-reports-issues-and-prs]
 == Bug reports, issues, and PRs
@@ -52,24 +50,9 @@ File a link:https://support.circleci.com/hc/en-us/requests/new[Support Ticket wi
 [#image-lifespan-eol]
 == Image lifespan / EOL
 
-We will keep a total of seven images at maximum, with a deprecation cycle happening once per year. The table below shows which images will be kept in each cycle. Generally we will aim to start EOL process within 3 months of a new version release.
-
-Current Deprecation (Jan 2024):
-
-[.table.table-striped]
-[cols=2*, options="header", stripes=even]
-|===
-| Release cycle
-| Image status
-
-| Current year
-| Keep all quarterly images of this year. Keep Q4 (October) image release of the last 2 years
-
-|===
-
-When an image is selected for deprecation and removal, we will create an announcement on our Discuss forum, along with reaching out via email to developers who have requested one of the deprecated images in their recent jobs.
+When a new API Level for Android is released we will release it to edge. We will give a 3 month warning before the default image will have oldest version no longer supported. We will create an announcement on our Discuss forum and along with additional outreach where possible.
 
-We will also plan brownouts to ensure users are aware of the approaching removal of deprecated images. Generally, we will aim to start an EOL process within 3 months of a new version release.
+Generally we will aim to start EOL process within 3 months of a new version release.
 
 [#exceptions]
 == Exceptions

jekyll/_cci2/android-machine-image.adoc

@@ -54,7 +54,7 @@ workflows:
           executor:
             name: android/android-machine
             resource-class: large
-            tag: 2021.10.1
+            tag: default
 ```
 
 [#more-complex-orb-usage]
@@ -75,7 +75,7 @@ jobs:
     executor:
       name: android/android-machine
       resource-class: large
-      tag: 2021.10.1
+      tag: default
     steps:
       - checkout
       # Create an AVD named "myavd"

jekyll/_cci2/linux-cuda-images-support-policy.adoc

@@ -20,9 +20,9 @@ This document outlines the xref:using-gpu#linux-gpu[CircleCI Linux CUDA image] r
 [#release-policy]
 == Release policy
 
-The CircleCI CUDA images are based on our Linux VM machine images for the purpose of providing an image that can leverage the additional processing capabilities of CircleCI’s GPU executor.
+The CircleCI CUDA images are based on our Linux VM machine images. This provides an image that can leverage the additional processing capabilities of CircleCI’s GPU executor.
 
-We aim to support the three most recent minor versions (or three most recent even numbered minor versions, if minor version >= `6`) of the two most recent and supported major CUDA releases. We closely track Nvidia’s own release cycle and aim to release our images within a week of the CUDA release.
+We aim to support the two most recent and supported major CUDA releases. We closely track Nvidia’s own release cycle and aim to release our images within a week of the CUDA release.
 
 The release policy is not an SLA (service level agreement). We can not, and do not, provide an official SLA turnaround time for new CUDA images.
 
@@ -42,7 +42,7 @@ The following tags are available for the CircleCI Linux CUDA images:
 [#critical-cve-patches]
 == Critical CVE patches
 
-When critical CVEs are disclosed that affect the versions of the operating system or software stack in either Linux or Windows images, we will investigate the impact that this has on our images being used across CircleCI execution environments.
+When critical CVEs are disclosed around the operating system or software stack of this image, we will investigate the impact this has on the image within the CircleCI execution environment.
 
 In most cases, due to the ephemeral and isolated nature of the environment, it is not necessary to patch these images. We will always communicate our stance on these disclosures via our link:https://discuss.circleci.com/[Discuss Forum].
 
@@ -101,7 +101,7 @@ A minor version release -- CUDA 11.8:
 
 Once a new even numbered minor version is released, that version will be added and the oldest existing version will be removed, provided that more than 3 minor versions exist.
 
-When an image is selected for deprecation and removal, we will create an announcement on our Discuss forum, along with reaching out via email to developers who have requested one of the deprecated images in their recent jobs. We will also plan brownouts to help ensure you are aware of the approaching removal of deprecated images.
+When an image is selected for deprecation and removal, we will create an announcement on our Discuss forum and along with additional outreach where possible.
 
 [#exceptions]
 == Exceptions

jekyll/_cci2/linux-vm-support-policy.adoc

@@ -31,18 +31,14 @@ Tags we support for this image (tag is what is specified in `.circleci/config.ym
 
 - `current` version of the image will receive updates approximately every three months.
 
-- `previous` version of the image will receive the previous version of `current`.
-
 - `edge` tags are reserved for previews of new releases, which will initially point to this tag. The edge tags may include incremental updates to the current quarterly (every 3 months) image release, which may change without notice, and is not recommended to be used for production CI workloads. `current` will be updated with these changes after a period of stability.
 
-- Date based tagging: The Ubuntu LTS based images have the image slug format of: `ubuntu-<LTS version>:<year>.<month>.<patch>`, such as `ubuntu-2204:2023.10.1`. We recommend using the `default` version and not pinning to a date version.
-
-We always aim to release a version of this image every three months.
+We always aim to release a version of this image every three months. Tags will be supported on all versions we support.
 
 [#critical-cve-patches]
 == Critical CVE patches
 
-When critical CVEs are disclosed that affect the versions of the operating system or software stack in Linux VM images, we will investigate the impact that this has on our images being used within the CircleCI execution environment.  If customers are impacted by these CVEs we will push a patch fix to the released image(s). This image will supersede the original image.
+When critical CVEs are disclosed around the operating system or software stack of this image, we will investigate the impact this has on the image within the CircleCI execution environment. If customers are impacted by these CVEs we will push a patch fix to the released image(s). This image will supersede the original image.
 
 [#bug-reports-issues-and-prs]
 == Bug reports, issues, and PRs
@@ -63,10 +59,8 @@ Current Deprecation (Jan 2024):
 | Support
 
 | Ubuntu 20.04 LTS
-| Build quarterly images for current year and retain Q4 (October) release from the past two years.
 
 | Ubuntu 22.04 LTS
-| Quarterly images built and only Q4 image retained each year
 |===
 
 
@@ -82,13 +76,13 @@ Example: When Ubuntu 24.04 LTS is released
 | Deprecated and removed entirely
 
 | Ubuntu 22.04 LTS
-| Retain only Q4 (October) releases from past two years
+| `current` and `edge` tags retained
 
 | Ubuntu 24.04 LTS
-| Quarterly images built and only Q4 (October) image retained from each year
+| `current` and `edge` tags retained
 |===
 
-When an image is selected for deprecation and removal, we will create an announcement on our Discuss forum, along with reaching out via email to developers who have requested one of the deprecated images in their recent jobs.
+When an image is selected for deprecation and removal, we will create an announcement on our Discuss forum and along with additional outreach where possible.
 
 We will also plan brownouts to ensure users are aware of the approaching removal of deprecated images. Generally, we will aim to start an EOL process within 3 months of a new version release.
 

jekyll/_cci2/remote-docker-images-support-policy.adoc

@@ -21,7 +21,7 @@ This document outlines the xref:building-docker-images#[CircleCI remote Docker i
 
 The CircleCI remote Docker images are based on our Linux VM images with Docker installed for the purposes of providing a remote environment that can execute Docker commands within jobs on the Docker executor.
 
-We aim to support the latest two versions of the Docker Engine that are classified as within Security Support status.
+We aim to support the latest three versions of the Docker Engine that are classified as within Security Support status.
 
 Remote Docker images will be updated when a patch version is released upstream. Tags will be redirected to the updated images automatically as described in the xref:#tagging[tagging] section of this document. We will announce these releases on our link:https://discuss.circleci.com/[Discuss Forum].
 
@@ -36,14 +36,12 @@ For the latest major version of Docker:
 
 - `edge`: This tag is reserved for previews of new releases, which will initially point to this tag. The tag may include incremental updates relative to the current quarterly image release, which may change without notice, and is not recommended for production CI workloads.
 
-- `previous`: Once an `edge` image is promoted to `default`, the previous `default` image is moved to the `previous` tag.
-
-For the previous major version of Docker, we support a single tag following the format of `dockerXX`, for example, `docker23` for Docker 23. This tag will point to the latest patch version of the major release, and will be updated if any patch versions are issued upstream. We recommend using the default version.
+For the previous major version of Docker, we support a single tag following the format of `dockerXX`, for example, `docker27` for Docker 27. This tag will point to the latest patch version of the major release, and will be updated if any patch versions are issued upstream. We recommend using the default version.
 
 [#critical-cve-patches]
 == Critical CVE patches
 
-When critical CVEs are disclosed that affect the versions of the operating system or software stack in our remote Docker images, we will investigate the impact that this has on our images being used within the CircleCI execution environment.  If customers are impacted by these CVEs we will push a patch fix to the released image(s), this image will supersede the original image.
+When critical CVEs are disclosed around the operating system or software stack of this image, we will investigate the impact this has on the image within the CircleCI execution environment. If customers are impacted by these CVEs we will push a patch fix to the released image(s), this image will supersede the original image.
 
 [#bug-reports-issues-and-prs]
 == Bug reports, issues, and PRs
@@ -63,39 +61,39 @@ Current Deprecation:
 | Version
 | Support
 
-| Docker 20
-| We will support one version of Docker 20 with a tag of `20.10.24`
+| Docker 25
+| `docker25` tag is maintained for Docker 25 support
 
-| Docker 23
-| `docker23` tag is maintained for Docker 23 support
+| Docker 26
+| `docker26` tag is maintained for Docker 26 support
 
-| Docker 24
-| Set to `default`, `edge` and `previous` tags
+| Docker 27
+| Set to `default` and `edge` tags. `docker27` tag is maintained for Docker 27 as default tag as well.
 |===
 
-Example: When Docker 25 is released:
+Example: When Docker 28 is released:
 
 [.table.table-striped]
 [cols=2*, options="header", stripes=even]
 |===
 | Version
 | Support
 
-| Docker 20
+| Docker 25
 | Deprecated and removed
 
-| Docker 23
-| `docker23` tag is frozen and kept until next cycle
+| Docker 26
+| `docker26` tag kept until next cycle
 
-| Docker 24
-| Moved from `default`, `edge` and `previous` tags to `docker24` tag
+| Docker 27
+| Moved from `default` and `edge` tags to `docker27` tag only
 
-| Docker 25
-| Set to `default`, `edge` and `previous` tags
+| Docker 28
+| Set to `default` and `edge` tags. With `docker28` tag for pinning Docker version.
 |===
 
 
-When an image is selected for deprecation and removal, we will create an announcement on our Discuss forum, along with reaching out via email to developers who have requested one of the deprecated images in their recent jobs.
+When an image is selected for deprecation and removal, we will create an announcement on our Discuss forum and along with additional outreach where possible.
 
 We will also plan brownouts to ensure users are aware of the approaching removal of deprecated images. Generally, we will aim to start an EOL process within 3 months of a new version release
 

jekyll/_cci2/windows-images-support-policy.adoc

@@ -33,23 +33,19 @@ We support various tags for the Windows environment, allowing you to choose a su
 
 - `edge`: tags are reserved for previews of new releases, which will initially point to this tag. The `edge` tags may include incremental updates to the current quarterly image release, which may change without notice, and is not recommended to be used for production CI workloads. `current` will be updated with these changes after a period of stability.
 
-- `previous`: version of Windows Server will receive the previous version of `current`.
-
 We generally install the latest Major version of Visual Studio Community Edition that coincides with the Windows Server version in the image when it is built.
 
-We always aim to release a version of the supported windows images (for example, currently this is `Windows server 2019` and `Windows server 2022`) every 3 months. We recommend using the `default` version and not pinning to a date version.
+We always aim to release a version of the supported Windows images every 3 months. We recommend using the `default` version and not pinning to a date version.
 
 [#tagging-with-the-windows-orb]
 == Tagging with the Windows orb
 
 The variant of Windows Server can be specified by choosing the name parameter in the Windows orb. The most recent version of Windows Server will always be accessible via the `win/default` name, but previous versions require explicit definition, such as `win/server-2019`.
 
-Each quarterly (published every 3 months) image for the `current` tag Windows Server version is published to a date-based tag, such as `2023.10.1`, which can be explicitly defined in the version parameter of the orb.
-
 [#critical-cve-patches]
 == Critical CVE patches
 
-When critical CVEs are disclosed that affect the versions of the operating system or software stack in our Windows Images, we will investigate the impact that this has on our images being used within the CircleCI execution environment. If customers are impacted by these CVEs we will push a patch fix to the released image(s), this image will supersede the original image.
+When critical CVEs are disclosed around the operating system or software stack of this image, we will investigate the impact this has on the image within the CircleCI execution environment. If customers are impacted by these CVEs we will push a patch fix to the released image(s), this image will supersede the original image.
 
 [#bug-reports-issues-and-prs]
 == Bug reports, issues, and PRs
@@ -59,11 +55,11 @@ You can file a link:https://support.circleci.com/hc/en-us/requests/new[support t
 [#image-lifespan-eol]
 == Image lifespan / EOL
 
-Once the next major version of Windows Server is released by Microsoft, and generally available to customers, we will deprecate the oldest version of Windows Server that we support and schedule it to be removed.
+Once the next major version of Windows Server is released, we will deprecate the oldest version of Windows Server that we support and schedule it to be removed.
 
-After the new version of Windows Server has been released, we will then move the current Windows Server version into an extended support phase and move to the tagging system described in the <<tagging>> section of this document.
+After the new version of Windows Server has been released, we will then move the current Windows Server version into an extended support phase.
 
-Current deprecation (Jan 2024):
+Current deprecation:
 
 [.table.table-striped]
 [cols=2*, options="header", stripes=even]
@@ -72,10 +68,10 @@ Current deprecation (Jan 2024):
 | Support
 
 | Windows Server 2019
-| Build quarterly images and retain Q4 (October) releases from previous two years
+| `current` and `edge` tags retained
 
 | Windows Server 2022
-| Build quarterly images and only Q4 (October) releases retained each year
+| `current` and `edge` tags retained
 |===
 
 Example: When Windows Server 2025 is released
@@ -90,13 +86,13 @@ Example: When Windows Server 2025 is released
 | Deprecated and removed entirely
 
 | Windows Server 2022
-| Retain only current and past two Q4 (October) releases
+| `current` and `edge` tags retained
 
 | Windows Server 2025
-| Quarterly images built and only Q4 (October) image retained each year
+| `current` and `edge` tags retained
 |===
 
-When an image is selected for deprecation and removal, we will create an announcement on our Discuss forum, along with reaching out via email to developers who have requested one of the deprecated images in their recent jobs.
+When an image is selected for deprecation and removal, we will create an announcement on our Discuss forum and along with additional outreach where possible.
 
 We will also plan brownouts to ensure users are aware of the approaching removal of deprecated images. Generally, we will aim to start an EOL process within 3 months of a new version release.