# Community package: To LTS or not to LTS

## Context

Before Ansible 2.10, the project typically maintained N, N-1 for bug fixes and N-2 for security fixes, for example ([here](https://github.com/ansible/ansible/blob/0b4b832f9cbab4246ec9aab7bd36c0447e04549d/docs/docsite/rst/reference_appendices/release_and_maintenance.rst)):

When Ansible 3.0.0 released, we suggested that we would no longer ship updated releases for 2.10.x unless someone needed it or showed up to do the work. Unless mistaken, we have not seen interest from the community so far in pursuing updates for 2.10.x.

This document seeks to write down what are the implications of maintaining updates for 3.x once 4.x releases and how we might continue maintaining 4.x once 5.x releases and so on.

## About the ``ansible`` package on PyPi

Before delving into the details, some basics about the package so we are on the same wavelength:

- It's a package that depends on the latest version of ansible-core at the time of the initial release (i.e, ``ansible-core>=2.11,<2.12``)
- It's a package that includes a selected [list of over 85 collections](https://github.com/ansible-community/ansible-build-data/blob/main/3/ansible.in) and ships their [latest minor versions](https://github.com/ansible-community/ansible-build-data/blob/main/3/ansible-3.build)
- After Ansible 4.0.0, it will have major releases every 6 months (5.0.0, 6.0.0, and so on)
- It has minor releases every 3 weeks (3.1.0, 3.2.0, 3.3.0 and so on)

## The use case for maintaining the ``ansible`` package

Broadly speaking, maintaining the Ansible community package means allowing the included collections to be updated independently of ansible-core, adding new backwards-compatible features and security/bug fixes.

This is simple and convenient for users who privilege or otherwise prefer the "batteries included" approach of installing one package and getting all the modules and plugins.

Another appeal of the community package is to continue getting updates while limiting exposure to major and breaking changes by way of semantic versioning for the included collections as well as the package itself.

Users who want increased control over their installation might opt for ``ansible-core`` instead and then cherry-pick the collections they want from galaxy or elsewhere.
These users can get updates for collections that are otherwise included in the ``ansible`` package "out-of-band" by controlling which versions they download from galaxy.

## What it means to maintain N and N-1

There are benefits to continue maintaining 3.x once 4.x is released:

- It would allow users to continue getting updates for a time while they prepare to upgrade
- It would be consistent with how Ansible has historically maintained /at least/ N and N-1
- Included collections can continue shipping fixes by backporting to stable branches if they have such a mechanism in place

In practice, maintaining past major releases is not without questions and challenges that should be addressed in order to move forward:

- Not every collection has the concept of stable branches to which they continue backporting fixes: how to manage user expectations vs unfixed bugs and security issues ?
- What kind of burden does this place on the community and the collection maintainers ?
- Even considering improved automation and testing of the release process, who will do the work ?
- Would we continue shipping a minor release every three weeks ?

## What it means to not maintain N-1

If we no longer maintain 3.x once 4.x is out, it can play out in one of two ways:

1) While users will continue getting minor updates for ansible-core (due to pinning such as ``>=2.11,<2.12``), they will no longer receive updates for included collections. We would encourage users to upgrade to 4.x ASAP to benefit from bug and security fixes in spite of potential major/breaking changes.
2) We encourage users to use ``ansible-core`` and cherry-pick the collection versions they want. This shifts the burden of maintenance to the user while allowing them to continue receiving the updates they care about.

## Expectations and considerations for downstream users

Our decision is not without impact for downstream consumers of the package like Linux distributions who have release and maintenance cycles that far exceed 6 months. For example, the latest Debian stable still has Ansible 2.7.7.

## In summary

There are benefits to a longer maintenance cycle and while we are open to the idea, it is a non-negligible amount of work without even considering the implications of patching collections that do not backport bug and security fixes.

Maintaining a single major version of the `ansible` package for six months while providing the ability to install and update collections out-of-band leveraging `ansible-core` and `ansible-galaxy` is likely a good middle ground until the need for a longer maintenance cycle is voiced by the wider community.