# Roadmap # Ansible project 10.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See the [ansible-core 2.17 Roadmap](https://docs.ansible.com/ansible-core/devel/roadmap/ROADMAP_2_17.html) for the most recent updates on `ansible-core`.
## Release schedule 2024-04-01 ansible-core feature freeze, stable-2.17 branch created. 2024-04-08 Start of ansible-core 2.17 betas 2024-04-09 Ansible-10.0.0 alpha1[^1] 2024-04-29 First ansible-core 2.17 release candidate. 2024-04-30 Ansible-10.0.0 alpha2[^2] 2024-05-20 Ansible-core-2.17.0 released. 2024-05-20 Last day for collections to make backwards incompatible releases that will be accepted into Ansible-10. This includes adding new collections to Ansible 10.0.0; from now on new collections have to wait for 10.1.0 or later. 2024-05-21 Ansible-10.0.0 beta1 -- feature freeze[^3] (weekly beta releases; collection owners and interested users should test for bugs). 2024-05-28 Ansible-10.0.0 rc1[^4][^5] (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. 2024-05-31 Last day to trigger an Ansible-10.0.0rc2 release because of major defects in Ansible-10.0.0rc1. 2024-06-04 Ansible-10.0.0rc2 when necessary, otherwise Ansible-10.0.0 release. 2024-06-11 Ansible-10.0.0 release when Ansible-10.0.0rc2 was necessary. 2024-06-04 or 2023-06-11 Create the ansible-build-data directory and files for Ansible-11. 2024-06-17 Release of ansible-core 2.17.1. 2024-06-18 Release of Ansible-10.1.0 (bugfix + compatible features: every four weeks.) > [!NOTE] > Breaking changes will be introduced in Ansible 10.0.0. We encourage the use of deprecation periods that give advance notice of breaking changes at least one Ansible release before they are introduced. However, deprecation notices are not guaranteed to take place. > [!NOTE] > In general, it is in the discretion of the release manager to delay a release by 1-2 days for reasons such as personal (schedule) problems, technical problems (CI/infrastructure breakdown), and so on. However, in case two releases are planned for the same day, a release of the latest stable version takes precedence. This means that if a stable Ansible 10 release collides with a pre-release of Ansible 11, the latter will be delayed. If a Ansible 10 release collides with a stable Ansible 11 release, including 11.0.0, the Ansible 10 release will be delayed. ## Planned major changes - The netapp.aws collection will be removed as it is unmaintained (). - The gluster.gluster collection will be removed as it is unmaintained (). - The community.sap collection will be removed as it is deprecated (). - The netapp.azure collection will be removed as it is unmaintained (). - The netapp.elementsw collection will be removed as it is unmaintained (). - The netapp.um_info collection will be removed as it is unmaintained (). - The community.azure collection will be removed as it is deprecated (). - The hpe.nimble collection will be removed as it is unmaintained (). You can install removed collections manually with `ansible-galaxy collection install `. ## Ansible minor releases Ansible 10.x follows ansible-core-2.17.x releases, so releases will occur approximately every four weeks. If ansible-core delays a release for whatever reason, the next Ansible 10.x minor release will be delayed accordingly. Ansible 10.x minor releases may contain new features (including new collections) but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-10.0.0 ships with community.crypto 2.3.0, Ansible-10.1.0 could ship with community.crypto 2.4.0 but not community.crypto 3.0.0. > [!NOTE] > Minor and patch releases will stop when Ansible-11 is released. See the `Release and Maintenance Page ` for more information. > [!NOTE] > We will not provide bugfixes or security fixes for collections that do not provide updates for their major release cycle included in Ansible 10. For more information, reach out on a mailing list or a chat channel - see `communication` for more details. [^1]: In case there are any additional ansible-core beta releases or release candidates, we will try to do another Ansible-10.0.0 alpha release. This might mean that we will release Ansible-10.0.0 alpha2 earlier (and release Ansible-10.0.0 alpha3 or later on 2024-04-30) and / or release one or more additional alpha after 2024-04-30. [^2]: In case there are any additional ansible-core beta releases or release candidates, we will try to do another Ansible-10.0.0 alpha release. This might mean that we will release Ansible-10.0.0 alpha2 earlier (and release Ansible-10.0.0 alpha3 or later on 2024-04-30) and / or release one or more additional alpha after 2024-04-30. [^3]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-10.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. [^4]: After this date only changes blocking a release are accepted. Accepted changes require creating a new release candidate and may slip the final release date. [^5]: Collections will be updated to a new version only if a blocker is approved. Collection owners should discuss any blockers at a community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the [creating an Ansible Community Topic workflow](https://github.com/ansible-community/community-topics/blob/main/community_topics_workflow.md#creating-a-topic). # Ansible project 11.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See the [ansible-core 2.18 Roadmap](https://docs.ansible.com/ansible-core/devel/roadmap/ROADMAP_2_18.html) for the most recent updates on `ansible-core`.
## Release schedule 2024-09-16 ansible-core feature freeze, stable-2.18 branch created. 2024-09-23 Start of ansible-core 2.18 betas 2024-09-24 Ansible-11.0.0 alpha1[^1] 2024-10-14 First ansible-core 2.18 release candidate. 2024-10-15 Ansible-11.0.0 alpha2[^2] 2024-11-04 Ansible-core-2.18.0 released. 2024-11-04 Last day for collections to make backwards incompatible releases that will be accepted into Ansible-11. This includes adding new collections to Ansible 11.0.0; from now on new collections have to wait for 11.1.0 or later. 2024-11-05 Ansible-11.0.0 beta1 -- feature freeze[^3] (weekly beta releases; collection owners and interested users should test for bugs). 2024-11-12 Ansible-11.0.0 rc1[^4][^5] (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. 2024-11-15 Last day to trigger an Ansible-11.0.0rc2 release because of major defects in Ansible-11.0.0rc1. 2024-11-19 Ansible-11.0.0rc2 when necessary, otherwise Ansible-11.0.0 release. 2024-11-26 Ansible-11.0.0 release when Ansible-11.0.0rc2 was necessary. 2024-11-19 or 2023-11-26 Create the ansible-build-data directory and files for Ansible-12. 2024-12-02 Release of ansible-core 2.18.1. 2024-12-03 Release of Ansible-11.1.0 (bugfix + compatible features: every four weeks.) > [!NOTE] > Breaking changes will be introduced in Ansible 11.0.0. We encourage the use of deprecation periods that give advance notice of breaking changes at least one Ansible release before they are introduced. However, deprecation notices are not guaranteed to take place. > [!NOTE] > In general, it is in the discretion of the release manager to delay a release by 1-2 days for reasons such as personal (schedule) problems, technical problems (CI/infrastructure breakdown), and so on. However, in case two releases are planned for the same day, a release of the latest stable version takes precedence. This means that if a stable Ansible 11 release collides with a pre-release of Ansible 12, the latter will be delayed. If a Ansible 11 release collides with a stable Ansible 12 release, including 12.0.0, the Ansible 11 release will be delayed. ## Planned major changes - The inspur.sm collection will be removed as it is unmaintained (). - The netapp.storagegrid collection will be removed as it is unmaintained (). - The frr.frr collection will be removed as it is unmaintained (). - The openvswitch.openvswitch collection will be removed as it is unmaintained (). You can install removed collections manually with `ansible-galaxy collection install `. ## Ansible minor releases Ansible 11.x follows ansible-core-2.18.x releases, so releases will occur approximately every four weeks. If ansible-core delays a release for whatever reason, the next Ansible 11.x minor release will be delayed accordingly. Ansible 11.x minor releases may contain new features (including new collections) but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-11.0.0 ships with community.crypto 2.3.0, Ansible-11.1.0 could ship with community.crypto 2.4.0 but not community.crypto 3.0.0. > [!NOTE] > Minor and patch releases will stop when Ansible-13 is released. This will likely be in November 2025, at the end of the Ansible Core 2.18 critical bugfix support lifecycle. This is approximately six months longer than regular Ansible releases. See the `Release and Maintenance Page ` for more information. > [!NOTE] > We will not provide bugfixes or security fixes for collections that do not provide updates for their major release cycle included in Ansible 11. ## Communication You can submit feedback on the current roadmap by creating a `community topic`. Visit the `Ansible communication guide` for details on how to join and use Ansible communication platforms. [^1]: In case there are any additional ansible-core beta releases or release candidates, we will try to do another Ansible-11.0.0 alpha release. This might mean that we will release Ansible-11.0.0 alpha2 earlier (and release Ansible-11.0.0 alpha3 or later on 2024-10-15) and / or release one or more additional alpha after 2024-10-15. [^2]: In case there are any additional ansible-core beta releases or release candidates, we will try to do another Ansible-11.0.0 alpha release. This might mean that we will release Ansible-11.0.0 alpha2 earlier (and release Ansible-11.0.0 alpha3 or later on 2024-10-15) and / or release one or more additional alpha after 2024-10-15. [^3]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-11.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. [^4]: After this date only changes blocking a release are accepted. Accepted changes require creating a new release candidate and may slip the final release date. [^5]: Collections will be updated to a new version only if a blocker is approved. Collection owners should discuss any blockers at a community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the [creating an Ansible Community Topic workflow](https://github.com/ansible-community/community-topics/blob/main/community_topics_workflow.md#creating-a-topic). # Ansible project 12.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See the [ansible-core 2.19 Roadmap](https://docs.ansible.com/ansible-core/devel/roadmap/ROADMAP_2_19.html) for the most recent updates on `ansible-core`.
## Release schedule The schedule has been updated to match the `ansible-core 2.19 release schedule `. If that one gets modified again, the Ansible 12 pre-release and release dates will be shifted accordingly, and potentially more pre-releases will be inserted. 2025-04-14 ansible-core feature freeze, stable-2.19 branch created. 2025-04-14 Start of ansible-core 2.19 betas. 2025-04-16 Ansible-12.0.0 alpha1; there will be more alpha releases usually following additional ansible-core 2.19 betas. 2025-06-30 First ansible-core 2.19 release candidate. 2025-07-01 Ansible-12.0.0 alphaX; there might be more alpha releases following additional ansible-core 2.19 release candidates. 2025-07-21 Ansible-core-2.19.0 released. 2025-07-21 Last day for collections to make backwards incompatible releases that will be accepted into Ansible-12. This includes adding new collections to Ansible 12.0.0; from now on new collections have to wait for 12.1.0 or later. 2025-07-22 Ansible-12.0.0 beta1 -- feature freeze[^1] (collection owners and interested users should test for bugs). 2025-07-29 Ansible-12.0.0 rc1[^2][^3] (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. 2025-08-01 Last day to trigger an Ansible-12.0.0rc2 release because of major defects in Ansible-12.0.0rc1. 2025-08-05 Ansible-12.0.0rc2 when necessary, otherwise Ansible-12.0.0 release. 2025-08-12 Ansible-12.0.0 release when Ansible-12.0.0rc2 was necessary. 2025-08-05 or 2025-08-12 Create the ansible-build-data directory and files for Ansible-13. 2025-08-18 Release of ansible-core 2.19.1. 2025-08-19 Release of Ansible-12.1.0 (bugfix + compatible features: every four weeks.) > [!NOTE] > Breaking changes will be introduced in Ansible 12.0.0. We encourage the use of deprecation periods that give advance notice of breaking changes at least one Ansible release before they are introduced. However, deprecation notices are not guaranteed to take place. > [!NOTE] > In general, it is in the discretion of the release manager to delay a release by 1-2 days for reasons such as personal (schedule) problems, technical problems (CI/infrastructure breakdown), and so on. However, in case two releases are planned for the same day, a release of the latest stable version takes precedence. This means that if a stable Ansible 12 release collides with a pre-release of Ansible 13, the latter will be delayed. If an Ansible 12 release collides with a stable Ansible 13 release, including 13.0.0, the Ansible 12 release will be delayed. ## Planned major changes - The inspur.sm collection will be removed as it is unmaintained (). - The netapp.storagegrid collection will be removed as it is unmaintained (). - The frr.frr collection will be removed as it is unmaintained (). - The openvswitch.openvswitch collection will be removed as it is unmaintained (). You can install removed collections manually with `ansible-galaxy collection install `. ## Ansible minor releases Ansible 12.x follows ansible-core-2.19.x releases, so releases will occur approximately every four weeks. If ansible-core delays a release for whatever reason, the next Ansible 12.x minor release will be delayed accordingly. Ansible 12.x minor releases may contain new features (including new collections) but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-12.0.0 ships with community.crypto 2.3.0, Ansible-12.1.0 could ship with community.crypto 2.4.0 but not community.crypto 3.0.0. > [!NOTE] > Minor and patch releases will stop when Ansible-13 is released. See the `Release and Maintenance Page ` for more information. > [!NOTE] > We will not provide bugfixes or security fixes for collections that do not provide updates for their major release cycle included in Ansible 12. ## Communication You can submit feedback on the current roadmap by creating a `community topic`. Visit the `Ansible communication guide` for details on how to join and use Ansible communication platforms. [^1]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-12.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. [^2]: After this date only changes blocking a release are accepted. Accepted changes require creating a new release candidate and may slip the final release date. [^3]: Collections will be updated to a new version only if a blocker is approved. Collection owners should discuss any blockers at a community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the [creating an Ansible Community Topic workflow](https://docs.ansible.com/projects/ansible/devel/community/steering/community_topics_workflow.html#creating-a-topic). # Ansible project 13.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See the `ansible-core 2.20 Roadmap ` for the most recent updates on `ansible-core`.
## Release schedule The schedule has been updated to match the `ansible-core 2.20 release schedule `. If that one gets modified again, the Ansible 12 pre-release and release dates will be shifted accordingly, and potentially more pre-releases will be inserted. 2025-09-15 ansible-core feature freeze. 2025-09-22 Start of ansible-core 2.20 betas. 2025-09-23 Ansible-13.0.0 alpha1; there will be more alpha releases usually following additional ansible-core 2.20 betas. 2025-10-13 First ansible-core 2.20 release candidate. 2025-10-14 Ansible-13.0.0 alphaX; there might be more alpha releases following additional ansible-core 2.19 release candidates. 2025-11-03 Ansible-core-2.20.0 released. 2025-11-03 Last day for collections to make backwards incompatible releases that will be accepted into Ansible-13. This includes adding new collections to Ansible 13.0.0; from now on new collections have to wait for 13.1.0 or later. 2025-11-04 Ansible-13.0.0 beta1 -- feature freeze[^1] (collection owners and interested users should test for bugs). 2025-11-11 Ansible-13.0.0 rc1[^2][^3] (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. 2025-11-14 Last day to trigger an Ansible-13.0.0rc2 release because of major defects in Ansible-13.0.0rc1. 2025-11-18 Ansible-13.0.0rc2 when necessary, otherwise Ansible-13.0.0 release. 2025-11-25 Ansible-13.0.0 release when Ansible-13.0.0rc2 was necessary. 2025-11-18 or 2025-11-25 Create the ansible-build-data directory and files for Ansible-14. 2025-12-01 Release of ansible-core 2.20.1. 2025-12-02 Release of Ansible-13.1.0 (bugfix + compatible features: every four weeks.) > [!NOTE] > Breaking changes will be introduced in Ansible 13.0.0. We encourage the use of deprecation periods that give advance notice of breaking changes at least one Ansible release before they are introduced. However, deprecation notices are not guaranteed to take place. > [!NOTE] > In general, it is in the discretion of the release manager to delay a release by 1-2 days for reasons such as personal (schedule) problems, technical problems (CI/infrastructure breakdown), and so on. However, in case two releases are planned for the same day, a release of the latest stable version takes precedence. This means that if a stable Ansible 13 release collides with a pre-release of Ansible 14, the latter will be delayed. If an Ansible 13 release collides with a stable Ansible 14 release, including 14.0.0, the Ansible 13 release will be delayed. ## Ansible minor releases Ansible 13.x follows ansible-core-2.20.x releases, so releases will occur approximately every four weeks. If ansible-core delays a release for whatever reason, the next Ansible 13.x minor release will usually (but not always) be delayed accordingly. Ansible 13.x minor releases may contain new features (including new collections) but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-13.0.0 ships with community.crypto 3.3.0, Ansible-13.1.0 could ship with community.crypto 3.4.0 but not community.crypto 4.0.0. > [!NOTE] > Minor and patch releases will stop when Ansible-14 is released. See the `Release and Maintenance Page ` for more information. > [!NOTE] > We will not provide bugfixes or security fixes for collections that do not provide updates for their major release cycle included in Ansible 13. ## Communication You can submit feedback on the current roadmap by creating a `community topic`. Visit the `Ansible communication guide` for details on how to join and use Ansible communication platforms. [^1]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 3.3.0; Ansible-13.0.0 could ship with community.crypto 3.3.1. It would not ship with community.crypto 3.4.0. [^2]: After this date only changes blocking a release are accepted. Accepted changes require creating a new release candidate and may slip the final release date. [^3]: Collections will be updated to a new version only if a blocker is approved. Collection owners should discuss any blockers at a community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `creating an Ansible Community Topic workflow `. # Ansible project 14.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See the `ansible-core 2.21 Roadmap ` for the most recent updates on `ansible-core`.
## Release schedule The schedule has been updated to match the `ansible-core 2.21 release schedule `. If that one gets modified again, the Ansible 14 pre-release and release dates will be shifted accordingly, and potentially more pre-releases will be inserted. 2026-03-30 ansible-core feature freeze. 2026-04-06 Start of ansible-core 2.21 betas. 2026-04-07 Ansible-14.0.0 alpha1; there will be more alpha releases usually following additional ansible-core 2.21 betas. 2026-04-27 First ansible-core 2.21 release candidate. 2026-04-28 Ansible-14.0.0 alphaX; there might be more alpha releases following additional ansible-core 2.21 release candidates. 2026-05-18 Ansible-core-2.21.0 released. 2026-05-18 Last day for collections to make backwards incompatible releases that will be accepted into Ansible-14. This includes adding new collections to Ansible 14.0.0; from now on new collections have to wait for 14.1.0 or later. 2026-05-19 Ansible-14.0.0 beta1 -- feature freeze[^1] (collection owners and interested users should test for bugs). 2026-05-26 Ansible-14.0.0 rc1[^2][^3] (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. 2026-05-29 Last day to trigger an Ansible-14.0.0rc2 release because of major defects in Ansible-14.0.0rc1. 2026-06-02 Ansible-14.0.0rc2 when necessary, otherwise Ansible-14.0.0 release. 2026-06-09 Ansible-14.0.0 release when Ansible-14.0.0rc2 was necessary. 2026-06-02 or 2026-06-09 Create the ansible-build-data directory and files for Ansible-15. 2026-06-15 Release of ansible-core 2.21.1. 2026-06-16 Release of Ansible-14.1.0 (bugfix + compatible features: every four weeks.) > [!NOTE] > Breaking changes will be introduced in Ansible 14.0.0. We encourage the use of deprecation periods that give advance notice of breaking changes at least one Ansible release before they are introduced. However, deprecation notices are not guaranteed to take place. > [!NOTE] > In general, it is in the discretion of the release manager to delay a release by 1-2 days for reasons such as personal (schedule) problems, technical problems (CI/infrastructure breakdown), and so on. However, in case two releases are planned for the same day, a release of the latest stable version takes precedence. This means that if a stable Ansible 14 release collides with a pre-release of Ansible 15, the latter will be delayed. If an Ansible 14 release collides with a stable Ansible 15 release, including 15.0.0, the Ansible 14 release will be delayed. ## Ansible minor releases Ansible 14.x follows ansible-core-2.21.x releases, so releases will occur approximately every four weeks. If ansible-core delays a release for whatever reason, the next Ansible 14.x minor release will usually (but not always) be delayed accordingly. Ansible 14.x minor releases may contain new features (including new collections) but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-14.0.0 ships with community.crypto 3.3.0, Ansible-14.1.0 could ship with community.crypto 3.4.0 but not community.crypto 4.0.0. > [!NOTE] > Minor and patch releases will stop when Ansible-15 is released. See the `Release and Maintenance Page ` for more information. > [!NOTE] > We will not provide bugfixes or security fixes for collections that do not provide updates for their major release cycle included in Ansible 14. ## Communication You can submit feedback on the current roadmap by creating a `community topic`. Visit the `Ansible communication guide` for details on how to join and use Ansible communication platforms. [^1]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 3.3.0; Ansible-14.0.0 could ship with community.crypto 3.3.1. It would not ship with community.crypto 3.4.0. [^2]: After this date only changes blocking a release are accepted. Accepted changes require creating a new release candidate and may slip the final release date. [^3]: Collections will be updated to a new version only if a blocker is approved. Collection owners should discuss any blockers at a community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `creating an Ansible Community Topic workflow `. # Ansible project 15.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See the `ansible-core 2.22 Roadmap ` for the most recent updates on `ansible-core`.
## Release schedule The schedule follows the `ansible-core 2.22 release schedule `. If that one gets modified, the Ansible 15 pre-release and release dates will be shifted accordingly, and potentially more pre-releases will be inserted. 2026-09-14 ansible-core feature freeze. 2026-09-21 Start of ansible-core 2.22 betas. 2026-09-22 Ansible-15.0.0 alpha1; there will be more alpha releases usually following additional ansible-core 2.22 betas. 2026-10-12 First ansible-core 2.22 release candidate. 2026-10-13 Ansible-15.0.0 alphaX; there might be more alpha releases following additional ansible-core 2.22 release candidates. 2026-11-02 Ansible-core-2.22.0 released. 2026-11-02 Last day for collections to make backwards incompatible releases that will be accepted into Ansible-15. This includes adding new collections to Ansible 15.0.0; from now on new collections have to wait for 15.1.0 or later. 2026-11-03 Ansible-15.0.0 beta1 -- feature freeze[^1] (collection owners and interested users should test for bugs). 2026-11-10 Ansible-15.0.0 rc1[^2][^3] (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. 2026-11-13 Last day to trigger an Ansible-15.0.0rc2 release because of major defects in Ansible-15.0.0rc1. 2026-11-17 Ansible-15.0.0rc2 when necessary, otherwise Ansible-15.0.0 release. 2026-11-24 Ansible-15.0.0 release when Ansible-15.0.0rc2 was necessary. 2026-11-17 or 2026-11-24 Create the ansible-build-data directory and files for Ansible-16. 2026-11-30 Release of ansible-core 2.22.1. 2026-12-01 Release of Ansible-15.1.0 (bugfix + compatible features: every four weeks.) > [!NOTE] > Breaking changes will be introduced in Ansible 15.0.0. We encourage the use of deprecation periods that give advance notice of breaking changes at least one Ansible release before they are introduced. However, deprecation notices are not guaranteed to take place. > [!NOTE] > In general, it is in the discretion of the release manager to delay a release by 1-2 days for reasons such as personal (schedule) problems, technical problems (CI/infrastructure breakdown), and so on. However, in case two releases are planned for the same day, a release of the latest stable version takes precedence. This means that if a stable Ansible 15 release collides with a pre-release of Ansible 16, the latter will be delayed. If an Ansible 15 release collides with a stable Ansible 16 release, including 16.0.0, the Ansible 15 release will be delayed. ## Ansible minor releases Ansible 15.x follows ansible-core-2.22.x releases, so releases will occur approximately every four weeks. If ansible-core delays a release for whatever reason, the next Ansible 15.x minor release will usually (but not always) be delayed accordingly. Ansible 15.x minor releases may contain new features (including new collections) but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-15.0.0 ships with community.crypto 3.3.0, Ansible-15.1.0 could ship with community.crypto 3.4.0 but not community.crypto 4.0.0. > [!NOTE] > Minor and patch releases will stop when Ansible-16 is released. See the `Release and Maintenance Page ` for more information. > [!NOTE] > We will not provide bugfixes or security fixes for collections that do not provide updates for their major release cycle included in Ansible 15. ## Communication You can submit feedback on the current roadmap by creating a `community topic`. Visit the `Ansible communication guide` for details on how to join and use Ansible communication platforms. [^1]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 3.3.0; Ansible-15.0.0 could ship with community.crypto 3.3.1. It would not ship with community.crypto 3.4.0. [^2]: After this date only changes blocking a release are accepted. Accepted changes require creating a new release candidate and may slip the final release date. [^3]: Collections will be updated to a new version only if a blocker is approved. Collection owners should discuss any blockers at a community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `creating an Ansible Community Topic workflow `. # Ansible project 2.10 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-base](https://pypi.org/project/ansible-base/) package as well. All dates are subject to change. See `base_roadmap_2_10` for the most recent updates on ansible-base.
## Release Schedule > [!NOTE] > Dates subject to change. > [!NOTE] > We plan to post weekly alpha releases to the [PyPI ansible project](https://pypi.org/project/ansible/) for testing. > [!WARNING] > We initially were going to have feature freeze on 2020-08-18. We tried this but decided to change course. Instead, we'll enter feature freeze when ansible-2.10.0 beta1 is released. - 2020-06-23: ansible-2.10 alpha freeze. No net new collections will be added to the `ansible-2.10` package after this date. - 2020-07-10: Ansible collections freeze date for content shuffling. Content should be in its final collection for the ansible-2.10 series of releases. No more content should move out of the `community.general` or `community.network` collections. - 2020-08-13: ansible-base 2.10 Release date, see `base_roadmap_2_10`. - 2020-08-14: final ansible-2.10 alpha. - 2020-09-01: ansible-2.10.0 beta1 and feature freeze. - No new modules or major features will be added after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-1.1.0; ansible-2.10.0 could ship with community-crypto-1.1.1. It would not ship with community-crypto-1.2.0. - 2020-09-08: ansible-2.10.0 beta2. - 2020-09-15: ansible-2.10.0 rc1 and final freeze. - After this date only changes blocking a release are accepted. - Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at the community meeting (on 9-17) to decide whether to bump the version of the collection for a fix. See the [Community meeting agenda](https://github.com/ansible/community/issues/539). \*\* Additional release candidates to be published as needed as blockers are fixed \*\* - 2020-09-22: ansible-2.10 GA release date. Ansible-2.10.x patch releases will occur roughly every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible-2.10.x patch releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed (example: Ansible-2.10 ships with community-crypto-1.1.0; ansible-2.10.1 may ship with community-crypto-1.2.0 but would not ship with community-crypto-2.0.0). > [!NOTE] > Minor releases will stop when `Ansible-3 ` is released. See the `Release and Maintenance Page ` for more information. Breaking changes may be introduced in ansible-3.0 although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before being changed incompatibly. For more information, reach out on a mailing list or a chat channel - see `communication` for more details. # Ansible project 3.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-base](https://pypi.org/project/ansible-base/) package as well. All dates are subject to change. Ansible 3.x.x includes `ansible-base` 2.10. See `base_roadmap_2_10` for the most recent updates on `ansible-base`.
## Release schedule > [!NOTE] > Ansible is switching from its traditional versioning scheme to [semantic versioning](https://semver.org/) starting with this release. So this version is 3.0.0 instead of 2.11.0. 2020-12-16 Finalize rules for net-new collections submitted for the ansible release. 2021-01-27 Final day for new collections to be **reviewed and approved**. They MUST be submitted prior to this to give reviewers a chance to look them over and for collection owners to fix any problems. 2021-02-02 Ansible-3.0.0-beta1 -- feature freeze[^1] 2021-02-09 Ansible-3.0.0-rc1 -- final freeze[^2][^3] 2021-02-16 Release of Ansible-3.0.0 2021-03-09 Release of Ansible-3.1.0 (bugfix + compatible features: every three weeks) > [!NOTE] > Breaking changes may be introduced in Ansible 3.0.0, although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before the breaking change happens. ## Ansible minor releases Ansible 3.x.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x. Ansible 3.x.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-3.0.0 ships with community-crypto-2.1.0; Ansible-3.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0). > [!NOTE] > Minor releases will stop when `Ansible-4 ` is released. See the `Release and Maintenance Page ` for more information. For more information, reach out on a mailing list or a chat channel - see `communication` for more details. ## ansible-base release Ansible 3.x.x works with `ansible-base` 2.10. See `base_roadmap_2_10` for details. [^1]: No new modules or major features accepted after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-2.1.0; ansible-3.0.0 could ship with community-crypto-2.1.1. It would not ship with community-crypto-2.2.0. [^2]: After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. [^3]: Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the [Community meeting agenda](https://github.com/ansible/community/issues/539). # Ansible project 4.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See `base_roadmap_2_11` for the most recent updates on `ansible-core`.
## Release schedule 2021-01-26 New Collections will be reviewed for inclusion in Ansible 4. Submit a request to include a new collection in this [GitHub Discussion](https://github.com/ansible-collections/ansible-inclusion/discussions/new). 2021-03-03 Ansible-4.0.0 alpha1 (biweekly `ansible` alphas. These are timed to coincide with the start of the `ansible-core-2.11` pre-releases). 2021-03-16 Ansible-4.0.0 alpha2 2021-03-30 Ansible-4.0.0 alpha3 2021-04-13 Last day for new collections to be submitted for inclusion in Ansible 4. Note that collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion. 2021-04-13 Ansible-4.0.0 alpha4 2021-04-14 Community Meeting topic: list any new collection reviews which block release. List any backwards incompatible collection releases that beta1 should try to accommodate. 2021-04-21 Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. 2021-04-26 Last day for new collections to be **reviewed and approved** for inclusion in Ansible 4. 2021-04-26 Last day for collections to make backwards incompatible releases that will be accepted into Ansible 4. 2021-04-27 Ansible-4.0.0 beta1 -- feature freeze[^1] (weekly beta releases. Collection owners and interested users should test for bugs). 2021-05-04 Ansible-4.0.0 beta2 2021-05-11 Ansible-4.0.0 rc1[^2][^3] (weekly release candidates as needed. Test and alert us to any blocker bugs). 2021-05-18 Ansible-4.0.0 release 2021-06-08 Release of Ansible-4.1.0 (bugfix + compatible features: every three weeks) > [!NOTE] > Breaking changes will be introduced in Ansible 4.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. ## Ansible minor releases Ansible 4.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.11.x. Ansible 4.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-4.0.0 ships with community-crypto-2.1.0; Ansible-4.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0). > [!NOTE] > Minor releases will stop when Ansible-5 is released. See the `Release and Maintenance Page ` for more information. For more information, reach out on a mailing list or a chat channel - see `communication` for more details. [^1]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-2.1.0; ansible-3.0.0 could ship with community-crypto-2.1.1. It would not ship with community-crypto-2.2.0. [^2]: After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. [^3]: Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a Community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the [Community meeting agenda](https://github.com/ansible/community/issues/539). # Ansible project 5.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See `core_roadmap_2_12` for the most recent updates on `ansible-core`.
## Release schedule 2021-04-14 New Collections can be reviewed for inclusion in Ansible 5. Submit a request to include a new collection in this [GitHub Discussion](https://github.com/ansible-collections/ansible-inclusion/discussions/new). 2021-09-24 ansible-core feature freeze. 2021-09-27 Start of ansible-core 2.12 betas (weekly, as needed). 2021-10-05 Ansible-5.0.0 alpha1 (roughly biweekly `ansible` alphas timed to coincide with `ansible-core-2.12` pre-releases). 2021-10-12 Last day for new collections to be submitted for inclusion in Ansible-5. Collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion. 2021-10-13 Community Meeting topic: List any new collection reviews which block release. List any backwards incompatible collection releases that beta1 should try to accommodate. 2021-10-18 First ansible-core release candidate, stable-2.12 branch created. 2021-10-19 Ansible-5.0.0 alpha2. 2021-10-26 Last day for new collections to be **reviewed and approved** for inclusion in Ansible-5. 2021-10-27 Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. 2021-11-02 Ansible-5.0.0 alpha3. 2021-11-08 Ansible-core-2.12 released. 2021-11-08 Last day for collections to make backwards incompatible releases that will be accepted into Ansible-5. 2021-11-09 Create the ansible-build-data directory and files for Ansible-6. New collection approvals will target this. 2021-11-09 Ansible-5.0.0 beta1 -- feature freeze[^1] (weekly beta releases; collection owners and interested users should test for bugs). 2021-11-16 Ansible-5.0.0 beta2. 2021-11-23 Ansible-5.0.0 rc1[^2][^3] (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. 2021-11-30 Ansible-5.0.0 release. 2021-12-21 Release of Ansible-5.1.0 (bugfix + compatible features: every three weeks.) > [!NOTE] > Breaking changes will be introduced in Ansible 5.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. ## Ansible minor releases Ansible 5.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.12.x. Ansible 5.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-5.0.0 ships with community.crypto 2.1.0; Ansible-5.1.0 may ship with community.crypto 2.2.0 but would not ship with community.crypto 3.0.0. > [!NOTE] > Minor releases will stop when Ansible-6 is released. See the `Release and Maintenance Page ` for more information. For more information, reach out on a mailing list or a chat channel - see `communication` for more details. [^1]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.1.0; Ansible-5.0.0 could ship with community.crypto 2.1.1. It would not ship with community.crypto 2.2.0. [^2]: After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. [^3]: Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the [Community IRC meeting agenda](https://github.com/ansible/community/issues/539). # Ansible project 6.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See the [ansible-core 2.13 Roadmap](https://docs.ansible.com/ansible-core/devel/roadmap/ROADMAP_2_13.html) for the most recent updates on `ansible-core`.
## Release schedule 2022-03-28 ansible-core feature freeze, stable-2.13 branch created. 2022-04-11 Start of ansible-core 2.13 betas (biweekly, as needed). 2022-04-12 Ansible-6.0.0 alpha1 (roughly biweekly `ansible` alphas timed to coincide with `ansible-core-2.13` pre-releases). 2022-04-27 Community Meeting topic: List any backwards incompatible collection releases that beta1 should try to accommodate. 2022-05-02 First ansible-core release candidate. 2022-05-03 Ansible-6.0.0 alpha2. 2022-05-11 Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. 2022-05-16 Ansible-core-2.13 released. 2022-05-17 Ansible-6.0.0 alpha3. 2022-05-23 Last day for collections to make backwards incompatible releases that will be accepted into Ansible-6. This includes adding new collections to Ansible 6.0.0; from now on new collections have to wait for 6.1.0 or later. 2022-05-24 Create the ansible-build-data directory and files for Ansible-7. 2022-05-24 Ansible-6.0.0 beta1 -- feature freeze[^1] (weekly beta releases; collection owners and interested users should test for bugs). 2022-05-31 Ansible-6.0.0 beta2. 2022-06-07 Ansible-6.0.0 rc1[^2][^3] (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. 2022-06-21 Ansible-6.0.0 release. 2022-07-12 Release of Ansible-6.1.0 (bugfix + compatible features: every three weeks.) > [!NOTE] > Breaking changes will be introduced in Ansible 6.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. ## Ansible minor releases Ansible 6.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.13.x. Ansible 6.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-6.0.0 ships with community.crypto 2.3.0; Ansible-6.1.0 may ship with community.crypto 2.4.0 but would not ship with community.crypto 3.0.0. > [!NOTE] > Minor releases will stop when Ansible-7 is released. See the `Release and Maintenance Page ` for more information. For more information, reach out on a mailing list or a chat channel - see `communication` for more details. ## Planned work More details can be found in [the community-topics planning issue](https://github.com/ansible-community/community-topics/issues/56). - Remove compatibility code which prevents parallel install of Ansible 6 with Ansible 2.9 or ansible-base 2.10 - Stop installing files (such as tests and development artifacts like editor configs) we have no use for - Ship Python wheels (as ansible-core 2.13 will likely also do) to improve installation performance [^1]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-6.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. [^2]: After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. [^3]: Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the [Community IRC meeting agenda](https://github.com/ansible/community/issues/539). # Ansible project 7.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See the [ansible-core 2.14 Roadmap](https://docs.ansible.com/ansible-core/devel/roadmap/ROADMAP_2_14.html) for the most recent updates on `ansible-core`.
## Release schedule 2022-09-19 ansible-core feature freeze, stable-2.14 branch created. 2022-09-26 Start of ansible-core 2.14 betas (biweekly, as needed). 2022-09-27 Ansible-7.0.0 alpha1 (roughly biweekly `ansible` alphas timed to coincide with `ansible-core-2.14` pre-releases). 2022-10-12 Community topic: List any backwards incompatible collection releases that beta1 should try to accommodate. 2022-10-17 First ansible-core 2.14 release candidate. 2022-10-25 Ansible-7.0.0 alpha2. 2022-10-26 Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline. 2022-11-07 Ansible-core-2.14.0 released. 2022-11-07 Last day for collections to make backwards incompatible releases that will be accepted into Ansible-7. This includes adding new collections to Ansible 7.0.0; from now on new collections have to wait for 7.1.0 or later. 2022-11-08 Create the ansible-build-data directory and files for Ansible-8. 2022-11-08 Ansible-7.0.0 beta1 -- feature freeze[^1] (weekly beta releases; collection owners and interested users should test for bugs). 2022-11-15 Ansible-7.0.0 rc1[^2][^3] (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. 2022-11-18 Last day to trigger an Ansible-7.0.0rc2 release because of major defects in Ansible-7.0.0rc1. 2022-11-22 Ansible-7.0.0rc2 when necessary, otherwise Ansible-7.0.0 release. 2022-11-29 Ansible-7.0.0 release when Ansible-7.0.0rc2 was necessary. 2022-12-05 Release of ansible-core 2.14.1. 2022-12-06 Release of Ansible-7.1.0 (bugfix + compatible features: every four weeks.) > [!NOTE] > Breaking changes will be introduced in Ansible 7.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. ## Ansible minor releases Ansible 7.x minor releases will occur approximately every four weeks if changes to collections have been made or to align to a later ansible-core-2.14.x. Ansible 7.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-7.0.0 ships with community.crypto 2.3.0; Ansible-7.1.0 may ship with community.crypto 2.4.0 but would not ship with community.crypto 3.0.0. > [!NOTE] > Minor releases will stop when Ansible-8 is released. See the `Release and Maintenance Page ` for more information. For more information, reach out on a mailing list or a chat channel - see `communication` for more details. [^1]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-7.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. [^2]: After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. [^3]: Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the [Community IRC meeting agenda](https://github.com/ansible/community/issues/539). # Ansible project 8.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See the [ansible-core 2.15 Roadmap](https://docs.ansible.com/ansible-core/devel/roadmap/ROADMAP_2_15.html) for the most recent updates on `ansible-core`.
## Release schedule 2023-03-31 ansible-core feature freeze, stable-2.15 branch created. 2023-04-03 Start of ansible-core 2.15 betas (biweekly, as needed). 2023-04-04 Ansible-8.0.0 alpha1 (roughly biweekly `ansible` alphas timed to coincide with `ansible-core-2.15` pre-releases). 2023-04-24 First ansible-core 2.15 release candidate. 2023-05-02 Another Ansible-8.0.0 alpha release. 2023-05-15 Ansible-core-2.15.0 released. 2023-05-15 Last day for collections to make backwards incompatible releases that will be accepted into Ansible-8. This includes adding new collections to Ansible 8.0.0; from now on new collections have to wait for 8.1.0 or later. 2023-05-16 Ansible-8.0.0 beta1 -- feature freeze[^1] (weekly beta releases; collection owners and interested users should test for bugs). 2023-05-23 Ansible-8.0.0 rc1[^2][^3] (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. 2023-05-26 Last day to trigger an Ansible-8.0.0rc2 release because of major defects in Ansible-8.0.0rc1. 2023-05-30 Ansible-8.0.0rc2 when necessary, otherwise Ansible-8.0.0 release. 2023-06-06 Ansible-8.0.0 release when Ansible-8.0.0rc2 was necessary. 2023-05-30 or 2023-06-06 Create the ansible-build-data directory and files for Ansible-9. 2023-06-20 Release of ansible-core 2.15.1. 2023-06-22 Release of Ansible-8.1.0 (bugfix + compatible features: every four weeks.) > [!NOTE] > Breaking changes will be introduced in Ansible 8.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed. > [!NOTE] > In general, it is in the discretion of the release manager to delay a release by 1-2 days for reasons such as personal (schedule) problems, technical problems (CI/infrastructure breakdown), and so on. However, in case two releases are planned for the same day, a release of the latest stable version takes precedence. This means that if a stable Ansible 8 release collides with a pre-release of Ansible 9, the latter will be delayed. If a Ansible 8 release collides with a stable Ansible 9 release, including 9.0.0, the Ansible 8 release will be delayed. ## Ansible minor releases Ansible 8.x minor releases will occur approximately every four weeks if changes to collections have been made or to align to a later ansible-core-2.15.x. Ansible 8.x minor releases may contain new features but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-8.0.0 ships with community.crypto 2.3.0; Ansible-8.1.0 may ship with community.crypto 2.4.0 but would not ship with community.crypto 3.0.0. > [!NOTE] > Minor and patch releases will stop when Ansible-9 is released. See the `Release and Maintenance Page ` for more information. For more information, reach out on a mailing list or a chat channel - see `communication` for more details. [^1]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-8.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. [^2]: After this date only changes blocking a release are accepted. Accepted changes require creating a new rc and may slip the final release date. [^3]: Collections will only be updated to a new version if a blocker is approved. Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the [Community IRC meeting agenda](https://github.com/ansible/community/issues/539). # Ansible project 9.0 This release schedule includes dates for the [ansible](https://pypi.org/project/ansible/) package, with a few dates for the [ansible-core](https://pypi.org/project/ansible-core/) package as well. All dates are subject to change. See the [ansible-core 2.16 Roadmap](https://docs.ansible.com/ansible-core/devel/roadmap/ROADMAP_2_16.html) for the most recent updates on `ansible-core`.
## Release schedule 2023-09-18 ansible-core feature freeze, stable-2.16 branch created. 2023-09-25 Start of ansible-core 2.16 betas 2023-09-26 Ansible-9.0.0 alpha1 2023-10-16 First ansible-core 2.16 release candidate. 2023-10-17 Ansible-9.0.0 alpha2 2023-11-06 Ansible-core-2.16.0 released. 2023-11-06 Last day for collections to make backwards incompatible releases that will be accepted into Ansible-9. This includes adding new collections to Ansible 9.0.0; from now on new collections have to wait for 9.1.0 or later. 2023-11-07 Ansible-9.0.0 beta1 -- feature freeze[^1] (weekly beta releases; collection owners and interested users should test for bugs). 2023-11-14 Ansible-9.0.0 rc1[^2][^3] (weekly release candidates as needed; test and alert us to any blocker bugs). Blocker bugs will slip release. 2023-11-17 Last day to trigger an Ansible-9.0.0rc2 release because of major defects in Ansible-9.0.0rc1. 2023-11-21 Ansible-9.0.0rc2 when necessary, otherwise Ansible-9.0.0 release. 2023-11-28 Ansible-9.0.0 release when Ansible-9.0.0rc2 was necessary. 2023-11-21 or 2023-11-28 Create the ansible-build-data directory and files for Ansible-10. 2023-12-04 Release of ansible-core 2.16.1. 2023-12-05 Release of Ansible-9.1.0 (bugfix + compatible features: every four weeks.) > [!NOTE] > Breaking changes will be introduced in Ansible 9.0.0. We encourage the use of deprecation periods that give advance notice of breaking changes at least one Ansible release before they are introduced. However, deprecation notices are not guaranteed to take place. > [!NOTE] > In general, it is in the discretion of the release manager to delay a release by 1-2 days for reasons such as personal (schedule) problems, technical problems (CI/infrastructure breakdown), and so on. However, in case two releases are planned for the same day, a release of the latest stable version takes precedence. This means that if a stable Ansible 9 release collides with a pre-release of Ansible 10, the latter will be delayed. If a Ansible 9 release collides with a stable Ansible 10 release, including 10.0.0, the Ansible 9 release will be delayed. ## Planned major changes - The cisco.nso collection will be removed as it is unmaintained (). - The community.fortios collection will be removed as it is unmaintained (). - The community.google collection will be removed as it is unmaintained (). - The community.skydive collection will be removed as it is unmaintained (). You can install removed collections manually with `ansible-galaxy collection install `. ## Ansible minor releases Ansible 9.x follows ansible-core-2.16.x releases, so releases will occur approximately every four weeks. If ansible-core delays a release for whatever reason, the next Ansible 9.x minor release will be delayed accordingly. Ansible 9.x minor releases may contain new features (including new collections) but not backwards incompatibilities. In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-9.0.0 ships with community.crypto 2.3.0, Ansible-9.1.0 could ship with community.crypto 2.4.0 but not community.crypto 3.0.0. > [!NOTE] > Minor and patch releases will stop in November 2024, at the end of the Ansible Core 2.16 critical bugfix support lifecycle. This is roughly half a year longer than regular Ansible releases. See the `Release and Maintenance Page ` for more information. > [!NOTE] > We will not provide bugfixes or security fixes for collections that do not provide updates for their major release cycle included in Ansible 9. For more information, reach out on a mailing list or a chat channel - see `communication` for more details. [^1]: No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.3.0; Ansible-9.0.0 could ship with community.crypto 2.3.1. It would not ship with community.crypto 2.4.0. [^2]: After this date only changes blocking a release are accepted. Accepted changes require creating a new release candidate and may slip the final release date. [^3]: Collections will be updated to a new version only if a blocker is approved. Collection owners should discuss any blockers with a `community-wg` tagged forum topic (before this freeze) to decide whether to bump the version of the collection for a fix. See the [Creating a Community working group topic](https://github.com/ansible-community/community-topics/blob/main/community_topics_workflow.md#creating-a-topic) for details. # Ansible-base 2.10
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-base release. > [!NOTE] > There is no Alpha phase in 2.10. > [!NOTE] > Dates subject to change. - 2020-06-16 Beta 1 **Feature freeze** No new functionality (including modules/plugins) to any code - 2020-07-21 Release Candidate 1 (bumped from 2020-07-14) - 2020-07-24 Release Candidate 2 - 2020-07-25 Release Candidate 3 - 2020-07-30 Release Candidate 4 - 2020-08-13 Release ## Release Manager @sivel ### Planned work - Migrate non-base plugins and modules from the `ansible/ansible` repository to smaller collection repositories - Add functionality to ease transition to collections, such as automatic redirects from the 2.9 names to the new FQCN of the plugin - Create new `ansible-base` package representing the `ansible/ansible` repository ### Additional Resources The 2.10 release of Ansible will fundamentally change the scope of plugins included in the `ansible/ansible` repository, by moving much of the plugins into smaller collection repositories that will be shipped through The following links have more information about this process: - - # Ansible-core 2.11
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. > [!NOTE] > There is no Alpha phase in 2.11. > [!NOTE] > Dates subject to change. - 2021-02-12 Feature Freeze No new functionality (including modules/plugins) to any code - 2021-03-02 Beta 1 - 2021-03-15 Beta 2 (if necessary) - 2021-03-29 Release Candidate 1 (and `stable-2.11` branching from `devel`) - 2021-04-12 Release Candidate 2 (if necessary) - 2021-04-26 Release ## Release Manager > Ansible Core Team ### Planned work - Rename `ansible-base` to `ansible-core`. - Improve UX of `ansible-galaxy collection` CLI, specifically as it relates to install and upgrade. - Add new Role Argument Spec feature that will allow a role to define an argument spec to be used in validating variables used by the role. - Bump the minimum Python version requirement for the controller to Python 3.8. There will be no breaking changes to this release, however `ansible-core` will only be packaged for Python 3.8+. `ansible-core==2.12` will include breaking changes requiring at least Python 3.8. - Introduce split-controller testing in `ansible-test` to separate dependencies for the controller from dependencies on the target. # Ansible-core 2.12
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. > [!NOTE] > There is no Alpha phase in 2.12. > [!NOTE] > Dates subject to change. - 2021-09-24 Feature Freeze (and `stable-2.12` branching from `devel`) No new functionality (including modules/plugins) to any code - 2021-09-27 Beta 1 - 2021-10-04 Beta 2 (if necessary) - 2021-10-18 Release Candidate 1 - 2021-10-25 Release Candidate 2 (if necessary) - 2021-11-08 Release ## Release Manager > Ansible Core Team ### Planned work - Bump the minimum Python version requirement for the controller to Python 3.8. This will be a hard requirement. - Deprecate Python 2.6 support for managed/target hosts. The release of `ansible-core==2.13` will remove Python 2.6 support. - Introduce split-controller testing in `ansible-test` to separate dependencies for the controller from dependencies on the target. - Extend the functionality of `module_defaults` `action_groups` to be created and presented by collections. ### Delayed work The following work has been delayed and retargeted for a future release - Implement object proxies, to expose restricted interfaces between parts of the code, and enable deprecations of attributes and variables. # Ansible-core 2.13
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. > [!NOTE] > There is no Alpha phase in 2.13. > [!NOTE] > Dates subject to change. #### Development Phase The `milestone` branch will be advanced at the start date of each development phase. - 2021-09-27 Development Phase 1 - 2021-12-13 Development Phase 2 - 2022-02-14 Development Phase 3 #### Release Phase - 2022-03-28 Feature Freeze (and `stable-2.13` branching from `devel`) No new functionality (including modules/plugins) to any code - 2022-04-11 Beta 1 - 2022-04-25 Beta 2 (if necessary) - 2022-05-02 Release Candidate 1 - 2022-05-16 Release ## Release Manager > Ansible Core Team ## Planned work - `ansible-doc` extended dump support for devtools integration - `ansible-galaxy` CLI collection verification, source, and trust - `jinja2` 3.0+ dependency - Consolidate template handling to always use `jinja2` native - Drop Python 2.6 support for module execution - Update the collection loader to Python 3.x loader API, due to removal of the Python 2 API in Python 3.12 - Modernize python packaging and installation ## Delayed work The following work has been delayed and retargeted for a future release - Data Tagging - Implement sidecar docs to support documenting filter/test plugins, as well as non Python modules # Ansible-core 2.14
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. > [!NOTE] > Dates subject to change. #### Development Phase The `milestone` branch will be advanced at the start date of each development phase. - 2022-05-02 Development Phase 1 - 2022-06-27 Development Phase 2 - 2022-08-08 Development Phase 3 #### Release Phase - 2022-09-19 Feature Freeze (and `stable-2.14` branching from `devel`) No new functionality (including modules/plugins) to any code - 2022-09-26 Beta 1 - 2022-10-17 Release Candidate 1 - 2022-11-07 Release > [!NOTE] > The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. ## Release Manager > Ansible Core Team ## Planned work - Implement sidecar docs to support documenting filter/test plugins, as well as non Python modules - Proxy Display over queue from forks - Move handler processing into new PlayIterator phase to use the configured strategy - Convert FieldAttribute to data descriptors to avoid complex meta classes - Drop Python 3.8 support for controller - Enforce running controller code with the Python locale and filesystem encoding set to UTF-8 ## Delayed work The following work has been delayed and retargeted for a future release: - Data Tagging # Ansible-core 2.15
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. > [!NOTE] > Dates subject to change. #### Development Phase The `milestone` branch will be advanced at the start date of each development phase. - 2022-10-17 Development Phase 1 - 2022-12-19 Development Phase 2 - 2023-02-20 Development Phase 3 #### Release Phase - 2023-03-31 Feature Freeze (and `stable-2.15` branching from `devel`) No new functionality (including modules/plugins) to any code - 2023-04-03 Beta 1 - 2023-04-24 Release Candidate 1 - 2023-05-15 Release > [!NOTE] > The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. ## Release Manager > Ansible Core Team ## Planned work - Proxy prompting over queue from forks ## Delayed work The following work has been delayed and retargeted for a future release: - Data Tagging # Ansible-core 2.16
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. > [!NOTE] > Dates subject to change. #### Development Phase The `milestone` branch will be advanced at the start date of each development phase. - 2023-05-01 Development Phase 1 - 2023-06-26 Development Phase 2 - 2023-08-07 Development Phase 3 #### Release Phase - 2023-09-18 Feature Freeze (and `stable-2.16` branching from `devel`) No new functionality (including modules/plugins) to any code - 2023-09-25 Beta 1 - 2023-10-16 Release Candidate 1 - 2023-11-06 Release > [!NOTE] > The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. ## Release Manager > Ansible Core Team ## Planned work - Drop Python 3.5 support for module execution - Drop Python 3.9 support for controller - Add support to `ansible-doc` for collections to declare new plugin types - Preserve display context when proxying display over the queue - Update `TaskExecutor` to not unnecessarily establish persistent `ansible-connection` when not needed - Remove deprecated functionality - Decrease incidental integration tests - Add controller type hinting for discrete areas of the code - Decrease testing sanity ignores - Update ansible-test container images and VMs - Update ansible-test dependencies ## Delayed work The following work has been delayed and retargeted for a future release: - Data Tagging # Ansible-core 2.17
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. > [!NOTE] > Dates subject to change. #### Development Phase The `milestone` branch will be advanced at the start date of each development phase. - 2023-10-16 Development Phase 1 - 2023-12-18 Development Phase 2 - 2024-02-19 Development Phase 3 #### Release Phase - 2024-04-01 Feature Freeze (and `stable-2.17` branching from `devel`) No new functionality (including modules/plugins) to any code - 2024-04-08 Beta 1 - 2024-04-29 Release Candidate 1 - 2024-05-20 Release > [!NOTE] > The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. ## Release Manager > Ansible Core Team ## Planned work - Drop Python 2.7 and 3.6 support for module execution - Remove deprecated functionality - Decrease incidental integration tests - Add controller type hinting for discrete areas of the code - Decrease testing sanity ignores - Update ansible-test container images and VMs - Update ansible-test dependencies ## Delayed work The following work has been delayed and retargeted for a future release: - Data Tagging # Ansible-core 2.18
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. > [!NOTE] > Dates subject to change. #### Development Phase The `milestone` branch will be advanced at the start date of each development phase, and the beta 1 release. - 2024-04-29 Development Phase 1 - 2024-06-24 Development Phase 2 - 2024-08-05 Development Phase 3 - 2024-09-23 Beta 1 #### Release Phase - 2024-09-16 Feature Freeze (and `stable-2.18` branching from `devel`) No new functionality (including modules/plugins) to any code - 2024-09-23 Beta 1 - 2024-10-14 Release Candidate 1 - 2024-11-04 Release > [!NOTE] > The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. ## Release Manager > Ansible Core Team ## Planned work - Drop Python 3.10, and add Python 3.13 for controller code - Drop Python 3.7, and add Python 3.13 for target code - Data Tagging - Add support to ansible-galaxy for new console.redhat.com service account auth - Finalize task object connection attribute for connection reporting in callbacks - Add break functionality for task loops - Add new non-local mount facts - Evaluate changes to strategy plugins to use the core strategy result processing for meta task results - Remove deprecated functionality - Decrease incidental integration tests - Add controller type hinting for discrete areas of the code - Decrease testing sanity ignores - Update ansible-test container images and VMs - Update ansible-test dependencies ## Delayed work The following work has been delayed and retargeted for a future release: - TBD # Ansible-core 2.19
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release. > [!NOTE] > Dates subject to change. #### Development Phase The `milestone` branch will be advanced at the start date of each development phase, and the beta 1 release. - 2024-10-14 Development Phase 1 - 2024-12-16 Development Phase 2 - 2025-02-17 Development Phase 3 - 2025-04-14 Beta 1 #### Release Phase - 2025-04-14 Feature Freeze (and `stable-2.19` branching from `devel`) No new functionality (including modules/plugins) to any code - 2025-04-14 Beta 1 - 2025-06-30 Release Candidate 1 (delayed, previously 2025-05-26) - 2025-07-21 Release (delayed, previously 2025-06-16) > [!NOTE] > The beta schedule allows for up to 6 releases and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. ## Release Manager > Ansible Core Team ## Planned work - Data Tagging - No longer allow forks to inherit stdio - `ansible-galaxy` CLI improvements - Support relative `download_url` in galaxy API responses - Add support to ansible-galaxy for new console.redhat.com service account auth - Evaluate pre-fork loop processing in strategy plugins - Add alternative to `sshpass` to the `ssh` connection plugin - Evaluate inclusion of `ssh-agent` handling - Deprecate `paramiko` connection plugin - Remove deprecated functionality - Decrease incidental integration tests - Add controller type hinting for discrete areas of the code - Decrease testing sanity ignores - Update ansible-test container images and VMs - Update ansible-test dependencies ## Delayed work The following work has been delayed and retargeted for a future release: - Register Projections - `ansible-galaxy` CLI improvements - Denote preferred collection - Add `uninstall` command - Support rollback on upgrade failures - Utilize `requires_ansible` during installs/upgrades - Move environment variable handling for modules out of shell plugins, to support private environment variables # Ansible-core 2.20
## Release Schedule ### Expected PRs must be raised sufficiently in advance of the following dates to have a chance of inclusion in this ansible-core release. > [!NOTE] > Dates are subject to change. #### Development Phase The `milestone` branch will be advanced at the start date of each development phase and the beta 1 release. - 2025-08-18 Development Phase 5 - 2025-09-22 Beta 1 #### Release Phase - 2025-09-15 Feature Freeze - 2025-09-22 Beta 1 - 2025-10-13 Release Candidate 1 - 2025-11-03 Release > [!NOTE] > The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. ## Release Manager Ansible Core Team ## Planned work - Drop Python 3.11 and add Python 3.14 for controller code - Drop Python 3.8 and add Python 3.14 for target code - Tech preview of Play argument specs - Support for 3rd party fact injection plugins - Register Projections - Remove deprecated functionality - Add controller type hinting for discrete areas of the code - Decrease testing sanity ignores - Update ansible-test container images and VMs - Update ansible-test dependencies ## Delayed work The following work has been delayed and retargeted for a future release: - TBD # Ansible-core 2.21
## Release Schedule ### Expected PRs must be raised sufficiently in advance of the following dates to have a chance of inclusion in this ansible-core release. > [!NOTE] > Dates are subject to change. #### Development Phase The `milestone` branch will be advanced at the start date of each development phase and the beta 1 release. - 2025-10-13 Development Phase 1 - 2025-11-10 Development Phase 2 - 2025-12-08 Development Phase 3 - 2026-01-05 Development Phase 4 - 2026-02-02 Development Phase 5 - 2026-03-02 Development Phase 6 #### Release Phase - 2026-03-30 Feature Freeze - 2026-04-06 Beta 1 - 2026-04-27 Release Candidate 1 - 2026-05-18 Release > [!NOTE] > The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. ## Release Manager Ansible Core Team ## Planned work - TBD ## Delayed work The following work has been delayed and retargeted for a future release: - TBD # Ansible-core 2.22
## Release Schedule ### Expected PRs must be raised sufficiently in advance of the following dates to have a chance of inclusion in this ansible-core release. > [!NOTE] > Dates are subject to change. #### Development Phase The `milestone` branch will be advanced at the start date of each development phase and the beta 1 release. - 2026-04-27 Development Phase 1 - 2026-05-25 Development Phase 2 - 2026-06-22 Development Phase 3 - 2026-07-20 Development Phase 4 - 2026-08-17 Development Phase 5 #### Release Phase - 2026-09-14 Feature Freeze - 2026-09-21 Beta 1 - 2026-10-12 Release Candidate 1 - 2026-11-02 Release > [!NOTE] > The beta and release candidate schedules allow for up to 3 releases on a weekly schedule depending on the necessity of creating a release. ## Release Manager Ansible Core Team ## Planned work - Add Python 3.15 support - Drop Python 3.12 for controller - Introspection/debugging of running core processes - Deprecate module/actions returning `skipped` - Enable Pipelining by default ## Delayed work The following work has been delayed and retargeted for a future release: - Drop Python 3.9 on target (delayed for 2.23) - Windows connection resiliency and performance improvements # Ansible 2.5 **Core Engine Freeze and Module Freeze: 22 January 2018** **Core and Curated Module Freeze: 22 January 2018** **Community Module Freeze: 7 February 2018** **Release Candidate 1 will be 21 February, 2018** **Target: March 2018** **Service Release schedule: every 2-3 weeks**
Topics
## Release Manager Matt Davis (IRC/GitHub: @nitzmahone) ## Engine improvements - Assemble module improvements - assemble just skips when in check mode, it should be able to test if there is a difference and changed=true/false. - The same with diff, it should work as template modules does - Handle Password reset prompts cleaner - Tasks stats for rescues and ignores - Normalize temp dir usage across all subsystems - Add option to set playbook dir for adhoc, inventory and console to allow for 'relative path loading' ## Ansible-Config - Extend config to more plugin types and update plugins to support the new config ## Inventory - ansible-inventory option to output group variable assignment and data (--export) - Create inventory plugins for: - aws ## Facts - Namespacing fact variables (with a config option) implemented in ansible/ansible PR [\#18445](https://github.com/ansible/ansible/pull/18445). Proposal found in ansible/proposals issue [\#17](https://github.com/ansible/proposals/issues/17). - Make fact collectors and gather_subset specs finer grained - Eliminate unneeded deps between fact collectors - Allow fact collectors to indicate if they need information from another fact collector to be gathered first. ## Static Loop Keyword - A simpler alternative to `with_`, `loop:` only takes a list - Remove complexity from loops, lookups are still available to users - Less confusing having a static directive vs a one that is dynamic depending on plugins loaded. ## Vault - Vault secrets client inc new 'keyring' client ## Runtime Check on Modules for Disabling - Filter on things like "supported_by" in module metadata - Provide users with an option of "warning, error or allow/ignore" - Configurable with ansible.cfg and environment variable ## Windows - Implement gather_subset on Windows facts - Fix Windows async + become to allow them to work together - Implement Windows become flags for controlling various modes **(done)** - logontype - elevation behavior - Convert win_updates to action plugin for auto reboot and extra features **(done)** - Spike out changing the connection over to PSRP instead of WSMV **(done- it is possible)** - Module updates - win_updates **(done)** - Fix win_updates to detect (or request) become - Add enable/disable features to win_updates - win_dsc further improvements **(done)** ## General Cloud - Make multi-cloud provisioning easier - Diff mode will output provisioning task results of ansible-playbook runs - Terraform module ## AWS - Focus on pull requests for various modules - Triage existing merges for modules - Module work - ec2_instance - ec2_vpc: Allow the addition of secondary IPv4 CIDRS to existing VPCs. - AWS Network Load Balancer support (NLB module, ASG support, and so on) - rds_instance ## Azure - Azure CLI auth **(done)** - Fix Azure module results to have "high-level" output instead of raw REST API dictionary **(partial, more to come in 2.6)** - Deprecate Azure automatic storage accounts in azure_rm_virtualmachine **(breaks on Azure Stack, punted until AS supports managed disks)** ## Network Roadmap - Refactor common network shared code into package **(done)** - Convert various nxos modules to use declarative intent **(done)** - Refactor various modules to use the cliconf plugin **(done)** - Add various missing declarative modules for supported platforms and functions **(done)** - Implement a feature that handles platform differences and feature unavailability **(done)** - netconf-config.py should provide control for deployment strategy - Create netconf connection plugin **(done)** - Create netconf fact module - Turn network_cli into a usable connection type **(done)** - Implements jsonrpc message passing for ansible-connection **(done)** - Improve logging for ansible-connection **(done)** - Improve stdout output for failures whilst using persistent connection **(done)** - Create IOS-XR NetConf Plugin and refactor iosxr modules to use netconf plugin **(done)** - Refactor junos modules to use netconf plugin **(done)** - Filters: Add a filter to convert XML response from a network device to JSON object **(done)** ## Documentation - Extend documentation to more plugins - Document vault-password-client scripts. - Network Documentation - New landing page (to replace intro_networking) **(done)** - Platform specific guides **(done)** - Walk through: Getting Started **(done)** - Networking and `become` **(done)** - Best practice **(done)** ## Contributor Quality of Life - Finish PSScriptAnalyer integration with ansible-test (for enforcing Powershell style) **(done)** - Resolve issues requiring skipping of some integration tests on Python 3. # Ansible 2.6
Topics
## Release Schedule ### Actual - 2018-05-17 Core Freeze (Engine and Core Modules/Plugins) - 2018-05-21 Alpha Release 1 - 2018-05-25 Community Freeze (Non-Core Modules/Plugins) - 2018-05-25 Branch stable-2.6 - 2018-05-30 Alpha Release 2 - 2018-06-05 Release Candidate 1 - 2018-06-08 Release Candidate 2 - 2018-06-18 Release Candidate 3 - 2018-06-25 Release Candidate 4 - 2018-06-26 Release Candidate 5 - 2018-06-28 Final Release ## Release Manager - 2.6.0-2.6.12 Matt Clay (IRC/GitHub: @mattclay) - 2.6.13+ Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger) ## Engine improvements - Version 2.6 is largely going to be a stabilization release for Core code. - Some of the items covered in this release, but are not limited to are the following: - `ansible-inventory` - `import_*` - `include_*` - Test coverage - Performance Testing ## Core Modules - Adopt-a-module Campaign - Review current status of all Core Modules - Reduce backlog of open issues against these modules ## Cloud Modules ## Network ### Connection work - New connection plugin: eAPI [proposal#102](https://github.com/ansible/proposals/issues/102) - New connection plugin: NX-API - Support for configurable options for network_cli & netconf ### Modules - New `net_get` - platform independent module for pulling configuration with SCP/SFTP over network_cli - New `net_put` - platform independent module for pushing configuration with SCP/SFTP over network_cli - New `netconf_get` - Netconf module to fetch configuration and state data [proposal#104](https://github.com/ansible/proposals/issues/104) ### Other Features - Stretch & tech preview: Configuration caching for network_cli. Opt-in feature to avoid `show running` performance hit ## Windows # Ansible 2.7
Topics
## Release Schedule ### Expected - 2018-08-23 Core Freeze (Engine and Core Modules/Plugins) - 2018-08-23 Alpha Release 1 - 2018-08-30 Community Freeze (Non-Core Modules/Plugins) - 2018-08-30 Beta Release 1 - 2018-09-06 Release Candidate 1 (If needed) - 2018-09-13 Release Candidate 2 (If needed) - 2018-09-20 Release Candidate 3 (If needed) - 2018-09-27 Release Candidate 4 (If needed) - 2018-10-04 General Availability ## Release Manager Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger) ## Cleaning Duty - Drop Py2.6 for controllers [Docs PR \#42971](https://github.com/ansible/ansible/pull/42971) and [issue \#42972](https://github.com/ansible/ansible/issues/42972) - Remove dependency on simplejson [issue \#42761](https://github.com/ansible/ansible/issues/42761) ## Engine Improvements - Performance improvement invoking Python modules [pr \#41749](https://github.com/ansible/ansible/pull/41749) - Jinja native types will allow for users to render a Python native type. [pr \#32738](https://github.com/ansible/ansible/pull/32738) ## Core Modules - Include feature changes and improvements - Create new argument `apply` that will allow for included tasks to inherit explicitly provided attributes. [pr \#39236](https://github.com/ansible/ansible/pull/39236) - Create "private" functionality for allowing vars/default to be exposed outside of roles. [pr \#41330](https://github.com/ansible/ansible/pull/41330) - Provide a parameter for the `template` module to output to different encoding formats [pr \#42171](https://github.com/ansible/ansible/pull/42171) - `reboot` module for Linux hosts (@samdoran) [pr \#35205](https://github.com/ansible/ansible/pull/35205) ## Cloud Modules ### General - Cloud auth plugin [proposal \#24](https://github.com/ansible/proposals/issues/24) ### AWS - Inventory plugin for RDS [pr \#41919](https://github.com/ansible/ansible/pull/41919) - Count support for ec2_instance - aws_eks module [pr \#41183](https://github.com/ansible/ansible/pull/41183) - Cloudformation stack sets support ([PR#41669](https://github.com/ansible/ansible/pull/41669)) - RDS instance and snapshot modules [pr \#39994](https://github.com/ansible/ansible/pull/39994) [pr \#43789](https://github.com/ansible/ansible/pull/43789) - Diff mode improvements for cloud modules [pr \#44533](https://github.com/ansible/ansible/pull/44533) ### Azure - Azure inventory plugin [issue \#42769](https://github.com/ansible/ansible/issues/42769) ## Network ### General - Refactor the APIs in cliconf ([issue \#39056](https://github.com/ansible/ansible/issues/39056)) and netconf ([issue \#39160](https://github.com/ansible/ansible/issues/39160)) plugins so that they have a uniform signature across supported network platforms. **done** ([PR \#41846](https://github.com/ansible/ansible/pull/41846)) ([PR \#43643](https://github.com/ansible/ansible/pull/43643)) ([PR \#43837](https://github.com/ansible/ansible/pull/43837)) ([PR \#43203](https://github.com/ansible/ansible/pull/43203)) ([PR \#42300](https://github.com/ansible/ansible/pull/42300)) ([PR \#44157](https://github.com/ansible/ansible/pull/44157)) ### Modules - New `cli_config` module [issue \#39228](https://github.com/ansible/ansible/issues/39228) **done** [PR \#42413](https://github.com/ansible/ansible/pull/42413). - New `cli_command` module [issue \#39284](https://github.com/ansible/ansible/issues/39284) - Refactor `netconf_config` module to add additional functionality. **done** [proposal \#104](https://github.com/ansible/proposals/issues/104) ([PR \#44379](https://github.com/ansible/ansible/pull/44379)) ## Windows ### General - Added new connection plugin that uses PSRP as the connection protocol [pr \#41729](https://github.com/ansible/ansible/pull/41729) ### Modules - Revamp Chocolatey to fix bugs and support offline installation [pr \#43013](https://github.com/ansible/ansible/pull/43013). - Add Chocolatey modules that can manage the following Chocolatey features > - [Sources](https://chocolatey.org/docs/commands-sources) [pr \#42790](https://github.com/ansible/ansible/pull/42790) > - [Features](https://chocolatey.org/docs/chocolatey-configuration#features) [pr \#42848](https://github.com/ansible/ansible/pull/42848) > - [Config](https://chocolatey.org/docs/chocolatey-configuration#config-settings) [pr \#42915](https://github.com/ansible/ansible/pull/42915) # Ansible 2.8
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this Ansible release. - 2019-04-04 Alpha 1 **Core freeze** No new features to `support:core` code. Includes no new options to existing Core modules - 2019-04-11 Beta 1 **Feature freeze** No new functionality (including modules/plugins) to any code - 2019-04-25 Release Candidate 1 - 2019-05-02 Release Candidate 2 - 2019-05-10 Release Candidate 3 - 2019-05-16 Release ## Release Manager Toshio Kuratomi (IRC: abadger1999; GitHub: @abadger) ### Planned work See the [Ansible 2.8 Project Board](https://github.com/ansible/ansible/projects/30) # Ansible 2.9
## Release Schedule ### Expected PRs must be raised well in advance of the dates below to have a chance of being included in this Ansible release. > [!NOTE] > There is no Alpha phase in 2.9. - 2019-08-29 Beta 1 **Feature freeze** No new functionality (including modules/plugins) to any code - 2019-09-19 Release Candidate 1 - 2019-10-03 Release Candidate 2 - 2019-10-10 Release Candidate 3 - 2019-10-17 Release Candidate 4 (if needed) - 2019-10-24 Release Candidate 5 (if needed) - 2019-10-31 Release ## Release Manager TBD Temporarily, Matt Davis (@nitzmahone) or Matt Clay (@mattclay) on IRC or github. ### Planned work See the [Ansible 2.9 Project Board](https://github.com/ansible/ansible/projects/34) # ansible-core Roadmaps The `ansible-core` team develops a roadmap for each major and minor `ansible-core` release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.10 and 2.11 have roadmaps, but 2.10.1 does not. We incorporate team and community feedback in each roadmap, and aim for further transparency and better inclusion of both community desires and submissions. Each roadmap offers a *best guess*, based on the `ansible-core` team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, and so on. Each roadmap is published both as an idea of what is upcoming in `ansible-core`, and as a medium for seeking further feedback from the community. You can submit feedback on the current roadmap by creating a topic on the `Ansible Forum` tagged with `ansible-core`. > [!NOTE] > To find the roadmap for upcoming releases, refer to the devel version of the Ansible documentation.
ROADMAP_2_22 ROADMAP_2_21 ROADMAP_2_20 ROADMAP_2_19 ROADMAP_2_18 ROADMAP_2_17 ROADMAP_2_16 ROADMAP_2_15 ROADMAP_2_14 ROADMAP_2_13 ROADMAP_2_12 ROADMAP_2_11 ROADMAP_2_10
# Ansible Roadmap The Ansible team develops a roadmap for each major and minor Ansible release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.10 and 2.11 have roadmaps, but 2.10.1 does not. We incorporate team and community feedback in each roadmap, and aim for further transparency and better inclusion of both community desires and submissions. Each roadmap offers a *best guess*, based on the Ansible team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, and so on. Each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. You can submit feedback on the current roadmap by creating a `community topic`. Visit the `Ansible communication guide` for details on how to join and use Ansible communication platforms. > [!NOTE] > To find the roadmap for upcoming releases, refer to the devel version of the Ansible documentation.
COLLECTIONS_15 COLLECTIONS_14 COLLECTIONS_13 COLLECTIONS_12 COLLECTIONS_11 COLLECTIONS_10 COLLECTIONS_9 COLLECTIONS_8 COLLECTIONS_7 COLLECTIONS_6 COLLECTIONS_5 COLLECTIONS_4 COLLECTIONS_3_0 COLLECTIONS_2_10 old_roadmap_index
# Roadmaps > [!NOTE] > To find the roadmap for upcoming releases, refer to the devel version of the Ansible documentation.
ansible_roadmap_index ansible_core_roadmap_index old_roadmap_index
# Older Roadmaps Older roadmaps are listed here to provide a history of the Ansible project.
ROADMAP_2_9 ROADMAP_2_8 ROADMAP_2_7 ROADMAP_2_6 ROADMAP_2_5