removed support for 3.8 and added doc

Author: 4gust

.github/workflows/python-package.yml

@@ -26,7 +26,7 @@ jobs:
     runs-on: ubuntu-22.04
     strategy:
       matrix:
-        python-version: ['3.8', '3.9', '3.10', '3.11', '3.12', '3.13', '3.14']
+        python-version: ['3.9', '3.10', '3.11', '3.12', '3.13', '3.14']
 
     steps:
     - uses: actions/checkout@v4

contributing.md

@@ -3,6 +3,15 @@
 Azure Active Directory SDK projects welcomes new contributors.  This document will guide you
 through the process.
 
+### SUPPORTED PYTHON VERSIONS
+
+The set of Python versions that MSAL Python supports, and the policy for
+adding/removing support, is documented in
+[doc/python_version_support_policy.md](doc/python_version_support_policy.md).
+Any change that adds or removes a Python version must update both that
+policy document and the supported-version declarations it lists
+(`setup.cfg`, the GitHub Actions matrix, and the cryptography test).
+
 ### CONTRIBUTOR LICENSE AGREEMENT
 
 Please visit [https://cla.microsoft.com/](https://cla.microsoft.com/) and sign the Contributor License

doc/python_version_support_policy.md

@@ -0,0 +1,93 @@
+# MSAL Python Version Support Policy
+
+This page describes the Python version support policy for the
+Microsoft Authentication Library for Python (MSAL Python), including
+end-of-support timelines for each Python version.
+
+This policy is aligned with the
+[Azure SDK for Python version support policy](https://github.com/Azure/azure-sdk-for-python/blob/main/doc/python_version_support_policy.md)
+so that MSAL Python and the Azure SDK can be consumed together without
+version conflicts.
+
+End of support means, in the MSAL Python context, that **new MSAL Python
+releases will no longer install on, be tested against, or accept bug
+fixes for those Python versions**. Older MSAL Python releases that did
+support those Python versions remain installable from PyPI via pip's
+`requires-python` resolution, so existing applications continue to work
+without change — they simply stop receiving new features and security
+fixes.
+
+## Policy
+
+MSAL Python supports a Python version while it is supported upstream by
+the Python core team (PSF), plus an additional **6-month grace window**
+after the PSF end-of-support date to give applications time to migrate.
+
+Concretely:
+
+- MSAL Python adds support for a new Python release as soon as practical
+  after that Python release ships a stable `.0`.
+- MSAL Python drops support for a Python version on the **first MSAL
+  Python release published on or after the SDK end-of-support date** for
+  that Python version (PSF end-of-support + ~6 months).
+- Dropping a Python version is a **breaking change** and is delivered in
+  a new minor or major release of MSAL Python, never in a patch.
+- The release notes (`RELEASES.md`) call out every Python-version
+  removal, and `setup.cfg` is updated in the same change to bump
+  `python_requires`, the trove classifiers, and any environment markers.
+
+> **Note:** The "MSAL Python End Of Support" date is inclusive — the
+> listed day is the last supported day, and the next day is the first
+> unsupported day.
+
+## Currently supported versions
+
+| Python Version | PSF End of Support | MSAL Python End Of Support |
+|----------------|--------------------|----------------------------|
+| 3.9 ([PEP 596](https://peps.python.org/pep-0596/#lifespan))  | October 2025 | April 30, 2026 *(see note)* |
+| 3.10 ([PEP 619](https://peps.python.org/pep-0619/#lifespan)) | October 2026 | April 30, 2027 |
+| 3.11 ([PEP 664](https://peps.python.org/pep-0664/#lifespan)) | October 2027 | April 30, 2028 |
+| 3.12 ([PEP 693](https://peps.python.org/pep-0693/#lifespan)) | October 2028 | April 30, 2029 |
+| 3.13 ([PEP 719](https://peps.python.org/pep-0719/#lifespan)) | October 2029 | April 30, 2030 |
+| 3.14 ([PEP 745](https://peps.python.org/pep-0745/#lifespan)) | October 2030 | April 30, 2031 |
+
+> **Note on Python 3.9:** Python 3.9 is past its policy end-of-support
+> date but is granted a one-time transition grace window in MSAL Python
+> while we adopt this policy and complete the removal of Python 3.8. It
+> will be removed in a subsequent MSAL Python release; the date will be
+> announced in `RELEASES.md` ahead of removal.
+
+## End-of-life versions (no longer supported)
+
+| Python Version | PSF End of Support | MSAL Python End Of Support |
+|----------------|--------------------|----------------------------|
+| 3.8 ([PEP 569](https://peps.python.org/pep-0569/#lifespan)) | October 2024 | April 2026 |
+| 3.7 ([PEP 537](https://peps.python.org/pep-0537/#lifespan)) | June 2023    | December 2023 |
+| 3.6 ([PEP 494](https://peps.python.org/pep-0494/#lifespan)) | December 2021 | August 2022 |
+| 2.7 ([PEP 373](https://peps.python.org/pep-0373/))           | April 2020    | January 2022 |
+
+## Implementation
+
+The supported Python versions are encoded in three places, which must be
+kept in sync with this policy:
+
+1. **`setup.cfg`** — `python_requires`, the `Programming Language ::
+   Python :: 3.x` trove classifiers, and any `python_version`
+   environment markers on optional dependencies (e.g. `pymsalruntime`).
+2. **`.github/workflows/python-package.yml`** — the `python-version`
+   matrix used by the `pytest` test job.
+3. **`tests/test_cryptography.py`** — the N+3 ceiling test that enforces
+   tracking the latest `cryptography` release. Newer `cryptography`
+   versions routinely drop EOL Python versions, which is the most common
+   forcing function for this policy.
+
+## Rationale
+
+MSAL Python depends transitively on `cryptography`, `requests`, and
+`PyJWT`. These libraries follow a similar policy and drop EOL Python
+versions roughly six months after PSF end-of-support. Continuing to
+support an EOL Python version in MSAL Python forces us to either pin
+those dependencies to old, unmaintained versions — exposing MSAL users
+to known CVEs — or to maintain conditional install metadata that breaks
+on every dependency bump. Aligning with the Azure SDK and upstream
+policies keeps MSAL Python simple, secure, and predictable.

setup.cfg

@@ -18,7 +18,6 @@ classifiers =
     Programming Language :: Python
     Programming Language :: Python :: 3 :: Only
     Programming Language :: Python :: 3
-    Programming Language :: Python :: 3.8
     Programming Language :: Python :: 3.9
     Programming Language :: Python :: 3.10
     Programming Language :: Python :: 3.11
@@ -38,8 +37,9 @@ project_urls =
 [options]
 include_package_data = False  # We used to ship LICENSE, but our __init__.py already mentions MIT
 packages = find:
-# Our test pipeline currently still covers Py37
-python_requires = >=3.8
+# Drop Python 3.8 because cryptography 48+ (and other key deps) no longer
+# support it; align with the cryptography upper bound policy.
+python_requires = >=3.9
 install_requires =
     requests>=2.0.0,<3
 
@@ -63,11 +63,11 @@ broker =
     # most existing MSAL Python apps do not have the redirect_uri needed by broker.
     #
     # We need pymsalruntime.CallbackData introduced in PyMsalRuntime 0.14
-    pymsalruntime>=0.14,<0.21; python_version>='3.8' and platform_system=='Windows'
+    pymsalruntime>=0.14,<0.21; python_version>='3.9' and platform_system=='Windows'
     # On Mac, PyMsalRuntime 0.17+ is expected to support SSH cert and ROPC
-    pymsalruntime>=0.17,<0.21; python_version>='3.8' and platform_system=='Darwin'
+    pymsalruntime>=0.17,<0.21; python_version>='3.9' and platform_system=='Darwin'
     # PyMsalRuntime 0.18+ is expected to support broker on Linux
-    pymsalruntime>=0.18,<0.21; python_version>='3.8' and platform_system=='Linux'
+    pymsalruntime>=0.18,<0.21; python_version>='3.9' and platform_system=='Linux'
 
 [options.packages.find]
 exclude =