Skip to content

Bump minimum Python version (3.10?) ahead of LTSv3 release #71916

@kartben

Description

@kartben

Introduction

Zephyr LTSv3, due circa July 2024, will be maintained for at least 2.5 years, i.e. until the end of 2026. In that time frame, Python 3.8 will have been long time EOL'd, and in fact so will Python 3.9 and 3.10 (see https://devguide.python.org/versions/#python-release-cycle).

In an effort to make LTS a viable long term option for downstream adopters, we should make sure the supported minimum Python version for Zephyr LTS3 is one that is maintained for the entire duration of the LTS.

Problem description

While Zephyr is not a product™, it is a project that is used in products. As such, it is important to ensure that the LTS versions are future-proof whenever we can.

Zephyr LTS2, shipped on Oct'21 with Python 3.6 as the supported/recommended version. Python 3.6 EOL'd just a few months later. Zephyr 3.6.99 currently supports/recommends Python 3.8, which is due to EOL in Oct'24.

What's more, sticking to Python 3.8 is actually preventing us to keep up-to-date with recent Sphinx releases, as they've dropped support for Python 3.8 since August 2023 (also see their support policy, which we may take inspiration from: "supports all minor versions of Python released in the past 42 months from the anticipated release date with a minimum of 3 minor versions").

Proposed change

Move away from Python 3.8 (which will in any case EOL before Zephyr 4.0 is out) to Python 3.10 (at least), as the minimum supported Python version for Zephyr LTSv3.
Python 3.10 sounds like a sensible choice as it will EOL roughly at the same time as LTSv3, and it's already the minimum version in e.g. current Ubuntu LTS.

Dependencies

  • Ensure new minimum version is fully tested in CI (might already be the case from a quick look at existing actions)
  • Update documentation (ex. getting started guide)
  • ...

Concerns and Unresolved Questions

  • Any decision made here would need to remain practical for folks not using the LTS, i.e. we maybe don't want to "force" too early of a Python upgrade for mainline users.

  • As reference points:

Alternatives

  • Status quo, i.e ship with whatever Python version happens to be the minimum supported version for the project at the time of the LTS release.

cc @aescolar @nashif as LTS release managers

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions