Skip to content

docs: include upstream python version info #1230

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
blackboxsw merged 2 commits into from
Feb 1, 2022
Merged

docs: include upstream python version info #1230

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f093ea9
docs: include upstream python version info
TheRealFalcon Feb 1, 2022
600a978
Add version table
TheRealFalcon Feb 1, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 22 additions & 5 deletions CONTRIBUTING.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -197,6 +197,26 @@ Design
This section captures design decisions that are helpful to know when
hacking on cloud-init.

Python Support
--------------
Cloud-init upstream currently supports Python 3.6 and above.
Copy link
Copy Markdown
Collaborator

@blackboxsw blackboxsw Feb 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's include the upstream version of cloud-init v. 22.1 as the point at which the python 3.6 min version support is expected.

Is it worth us trying to preserve a stable-21.4 branch at the cutoff point where 3.5 was dropped for other downstream reference? We did this for our python-2.7 drop via upstream/stable-19.4.
I think there is limited utility for these separate stable-* branches, as I don't think we've seen any downstream PRs against stable-19.4 for instance so I don't know if there is much demand there.

If we did want to capture/doc the python version deprecatoin branches in docs or process, this is the commit where upstream dropped 3.5 support I think is here.

GIven that other distributions might trail upstream significantly. Is it worth us having a table showing last upstream version which supports min python version supported?

cloud-init version min python version
22.1 python 3.6+
20.3 python 3.5+
19.4 python 2.7+

Copy link
Copy Markdown
Contributor Author

@TheRealFalcon TheRealFalcon Feb 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth us trying to preserve a stable-21.4 branch at the cutoff point where 3.5 was dropped for other downstream reference? We did this for our python-2.7 drop via upstream/stable-19.4.
I think there is limited utility for these separate stable-* branches, as I don't think we've seen any downstream PRs against stable-19.4 for instance so I don't know if there is much demand there.

I don't think we should do that. 2.7->3.x was a huge transition with a ton of breaking changes. Moving between 3.x versions should be much less impactful.

I can capture the table in the doc.


Cloud-init upstream will stay compatible with a particular python version
for 6 years after release. After 6 years, we will stop testing upstream
changes against the unsupported version of python and may introduce
breaking changes. This policy may change as needed.

The following table lists the cloud-init versions in which the
minimum python version changed:

================== ==================
Cloud-init version Python version
================== ==================
22.1 3.6+
20.3 3.5+
19.4 2.7+
================== ==================

Cloud Config Modules
--------------------

Expand All @@ -213,11 +233,8 @@ Type Annotations
----------------

The cloud-init codebase uses Python's annotation support for storing
type annotations in the style specified by `PEP-484`_. Their use in
the codebase is encouraged but with one important caveat: only
function annotations or comment annotations are supported, as the
variable annotations specified in `PEP-526`_ were introduced in Python
3.6.
type annotations in the style specified by `PEP-484`_ and `PEP-526`_.
Their use in the codebase is encouraged.

.. _PEP-484: https://www.python.org/dev/peps/pep-0484/
.. _PEP-526: https://www.python.org/dev/peps/pep-0526/
Expand Down