|
| 1 | +# MSAL Python Version Support Policy |
| 2 | + |
| 3 | +This page describes the Python version support policy for the |
| 4 | +Microsoft Authentication Library for Python (MSAL Python), including |
| 5 | +end-of-support timelines for each Python version. |
| 6 | + |
| 7 | +This policy is aligned with the |
| 8 | +[Azure SDK for Python version support policy](https://github.com/Azure/azure-sdk-for-python/blob/main/doc/python_version_support_policy.md) |
| 9 | +so that MSAL Python and the Azure SDK can be consumed together without |
| 10 | +version conflicts. |
| 11 | + |
| 12 | +End of support means, in the MSAL Python context, that **new MSAL Python |
| 13 | +releases will no longer install on, be tested against, or accept bug |
| 14 | +fixes for those Python versions**. Older MSAL Python releases that did |
| 15 | +support those Python versions remain installable from PyPI via pip's |
| 16 | +`requires-python` resolution, so existing applications continue to work |
| 17 | +without change — they simply stop receiving new features and security |
| 18 | +fixes. |
| 19 | + |
| 20 | +## Policy |
| 21 | + |
| 22 | +MSAL Python supports a Python version while it is supported upstream by |
| 23 | +the Python core team (PSF), plus an additional **6-month grace window** |
| 24 | +after the PSF end-of-support date to give applications time to migrate. |
| 25 | + |
| 26 | +Concretely: |
| 27 | + |
| 28 | +- MSAL Python adds support for a new Python release as soon as practical |
| 29 | + after that Python release ships a stable `.0`. |
| 30 | +- MSAL Python drops support for a Python version on the **first MSAL |
| 31 | + Python release published on or after the SDK end-of-support date** for |
| 32 | + that Python version (PSF end-of-support + ~6 months). |
| 33 | +- Dropping a Python version is a **breaking change** and is delivered in |
| 34 | + a new minor or major release of MSAL Python, never in a patch. |
| 35 | +- The release notes (`RELEASES.md`) call out every Python-version |
| 36 | + removal, and `setup.cfg` is updated in the same change to bump |
| 37 | + `python_requires`, the trove classifiers, and any environment markers. |
| 38 | + |
| 39 | +> **Note:** The "MSAL Python End Of Support" date is inclusive — the |
| 40 | +> listed day is the last supported day, and the next day is the first |
| 41 | +> unsupported day. |
| 42 | +
|
| 43 | +## Currently supported versions |
| 44 | + |
| 45 | +| Python Version | PSF End of Support | MSAL Python End Of Support | |
| 46 | +|----------------|--------------------|----------------------------| |
| 47 | +| 3.9 ([PEP 596](https://peps.python.org/pep-0596/#lifespan)) | October 2025 | April 30, 2026 *(see note)* | |
| 48 | +| 3.10 ([PEP 619](https://peps.python.org/pep-0619/#lifespan)) | October 2026 | April 30, 2027 | |
| 49 | +| 3.11 ([PEP 664](https://peps.python.org/pep-0664/#lifespan)) | October 2027 | April 30, 2028 | |
| 50 | +| 3.12 ([PEP 693](https://peps.python.org/pep-0693/#lifespan)) | October 2028 | April 30, 2029 | |
| 51 | +| 3.13 ([PEP 719](https://peps.python.org/pep-0719/#lifespan)) | October 2029 | April 30, 2030 | |
| 52 | +| 3.14 ([PEP 745](https://peps.python.org/pep-0745/#lifespan)) | October 2030 | April 30, 2031 | |
| 53 | + |
| 54 | +> **Note on Python 3.9:** Python 3.9 is past its policy end-of-support |
| 55 | +> date but is granted a one-time transition grace window in MSAL Python |
| 56 | +> while we adopt this policy and complete the removal of Python 3.8. It |
| 57 | +> will be removed in a subsequent MSAL Python release; the date will be |
| 58 | +> announced in `RELEASES.md` ahead of removal. |
| 59 | +
|
| 60 | +## End-of-life versions (no longer supported) |
| 61 | + |
| 62 | +| Python Version | PSF End of Support | MSAL Python End Of Support | |
| 63 | +|----------------|--------------------|----------------------------| |
| 64 | +| 3.8 ([PEP 569](https://peps.python.org/pep-0569/#lifespan)) | October 2024 | April 2026 | |
| 65 | +| 3.7 ([PEP 537](https://peps.python.org/pep-0537/#lifespan)) | June 2023 | December 2023 | |
| 66 | +| 3.6 ([PEP 494](https://peps.python.org/pep-0494/#lifespan)) | December 2021 | August 2022 | |
| 67 | +| 2.7 ([PEP 373](https://peps.python.org/pep-0373/)) | April 2020 | January 2022 | |
| 68 | + |
| 69 | +## Implementation |
| 70 | + |
| 71 | +The supported Python versions are encoded in three places, which must be |
| 72 | +kept in sync with this policy: |
| 73 | + |
| 74 | +1. **`setup.cfg`** — `python_requires`, the `Programming Language :: |
| 75 | + Python :: 3.x` trove classifiers, and any `python_version` |
| 76 | + environment markers on optional dependencies (e.g. `pymsalruntime`). |
| 77 | +2. **`.github/workflows/python-package.yml`** — the `python-version` |
| 78 | + matrix used by the `pytest` test job. |
| 79 | +3. **`tests/test_cryptography.py`** — the N+3 ceiling test that enforces |
| 80 | + tracking the latest `cryptography` release. Newer `cryptography` |
| 81 | + versions routinely drop EOL Python versions, which is the most common |
| 82 | + forcing function for this policy. |
| 83 | + |
| 84 | +## Rationale |
| 85 | + |
| 86 | +MSAL Python depends transitively on `cryptography`, `requests`, and |
| 87 | +`PyJWT`. These libraries follow a similar policy and drop EOL Python |
| 88 | +versions roughly six months after PSF end-of-support. Continuing to |
| 89 | +support an EOL Python version in MSAL Python forces us to either pin |
| 90 | +those dependencies to old, unmaintained versions — exposing MSAL users |
| 91 | +to known CVEs — or to maintain conditional install metadata that breaks |
| 92 | +on every dependency bump. Aligning with the Azure SDK and upstream |
| 93 | +policies keeps MSAL Python simple, secure, and predictable. |
0 commit comments