[associated vote ended on 2023-09-13] Which/how many versions of ansible(-base|-core) should a (community) collection support?

[felixfontein]

Summary

There are quite a few (community) collections that currently support every ansible-core/ansible-base/Ansible version down to Ansible 2.9, some of them simply because they never had a new major release since 1.0.0 (and thus no chance to drop support while sticking to semantic versioning). We should come up with guidelines for community collections which versions they should support, and which they can safely drop support for.

I'm creating this topic so we have a place to discuss this. To get the discussion going, I'll start with a concrete proposal for community.general - which is special since it has a new major release every half a year (synced with major Ansible releases), so it can drop support for older collections on a regular basis. (I'll do this in a separate comment so it's easier to link to it directly.)

[felixfontein]

Proposal for supported ansible-core versions for community.general

For every new major release of community.general, drop support for all ansible-core versions that have been End of Life for at least a couple of weeks before the release date.

What does this effectively mean?

Right now, community.general 7.x.y requires ansible-core 2.11+. ansible-core 2.11 and 2.12 are EOL (2.12 turned EOL around the time 7.0.0 was released). This would mean that c.g 8.0.0 would require ansible-core 2.13+, c.g 9.0.0 would require ansible-core 2.14+, etc. So basically c.g X.0.0 is released close to ansible-core 2.(X+8).0 and supports ansible-core 2.(X+5).0+.

What are the consequences for users?

Assume the latest community.general release is X.y.z.

• If you want new features for community.general, you need to use ansible-core 2.(X+5)+, so you can use c.g X or later; ansible-core 2.(X+5) is at least two years old by then;
• If you want bugfixes for community.general, you need to use ansible-core 2.(X+4)+, so you can use c.g (X-1) or later; ansible-core 2.(X+5) is at least 2.5 years old by then;
• If you want security fixes and major bugfixes for community.general, you need to use ansible-core 2.(X+3)+, so you can use c.g (X-2) or later; ansible-core 2.(X+5) is at least three years old by then;
• If you use ansible-core 2.(X+2) or before (which is at least 3.5 years old by then), you can only use EOL'ed versions of community.general that no longer receive any updates.

[felixfontein]

What do folks think of the following guideline for collection maintainers:

Try to make a new major release at least every two years, to drop support for EOL versions of ansible-core. If your collection is included in Ansible, try to align them with the Ansible feature freeze (i.e. do your major release shortly before it).

Obviously this isn't mandatory, so collection maintainers can also ignore it. But if they are unsure what to do with a ever-growing list of supported EOL versions of ansible-core, and they have no indication that someone really needs support for them, this would be a useful guideline to clean up from time to time.

[gotmax23]

Here's some data of which ansible-core verisons collections in ansible 8.1.0 claim to support in meta/runtime.yml: https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/ansible/report_version-8.1.0.txt

Many collections still claim support for ansible 2.9. Whether this is actually accurate or collections just forgot to update the file is an open question.

[russoz]

The recent versions of ansible-core also establish minimum versions of Python supported. I take it that the collections will follow those as well.

Can we finally kill Python 2?

[felixfontein]

Python 2 on the target side is still supported by current ansible-core versions, and it will probably stay for some more time (at least I haven't seen any indication that it's going to change soon). So I guess we need to wait some more for that...

On the controller side though, ansible-core 2.12 is Python 3.8+, so dropping support for ansible-core 2.11 (and earlier) means that you can use Python 3.8+ on the controller side. Unfortunately that does not applies to modules and module utils...

[mariolenz]

I think RHEL 9 doesn't ship Python 2 anymore, but RHEL 8 still did. However, it looks like it's not supported for the complete lifetime of RHEL 8:

The RHEL 8 AppStream Lifecycle Page puts the end date of RHEL 8's Python 2.7 package at June 2024.

After this date, customers are encouraged to upgrade to a later Python release such as Python 3. Customers may also continue with Python 2.7 as self-supported without official Red Hat Support.

I don't think Python 2 on the target will be dropped before that. Of course, this is just pure guesswork from my side.

[UnderGreen]

Unfortunately that does not applies to modules and module utils...

Does it apply to all modules? I can see a lot of modules interacting with APIs from localhost(controller in that case) and they would be still restricted to support 2.7.

[felixfontein]

@UnderGreen all modules in the collection have to compile with Python 2.7, and run in the sense that they emit a helpful error message (and not a syntax error, import error, or something else very unhelpful). The import and compile sanity tests also make sure that's the case.

[hille721]

@UnderGreen if the module is only interacting with APIs and nothing doing on the target system it can be an action plugin and don't need to support Python 2 anymore.

[felixfontein]

@hille721 an action plugin forces you to use the plugin on the controller. With a module, you can also run it from a remote machine which might be in the correct network (think of jump hosts) to actually access the API.

[hille721]

@felixfontein didn't had network restrictions in mind but yes that's a good point.

[mariolenz]

I think RHEL 9 doesn't ship Python 2 anymore, but RHEL 8 still did. However, it looks like it's not supported for the complete lifetime of RHEL 8:

The RHEL 8 AppStream Lifecycle Page puts the end date of RHEL 8's Python 2.7 package at June 2024.
After this date, customers are encouraged to upgrade to a later Python release such as Python 3. Customers may also continue with Python 2.7 as self-supported without official Red Hat Support.

I don't think Python 2 on the target will be dropped before that. Of course, this is just pure guesswork from my side.

FYI it looks like ansible-core will drop Python 2 in 2.17: ansible-collections/news-for-maintainers#54

[felixfontein]

That means that with my proposal, the first community.general version that no longer supports Python 2.7 is community.general 12.0.0. Considering that we currently are in the 7.x.y cycle, that's 2.5 more years.

[felixfontein]

I'll create a vote for #245 (comment) next week if nobody has an objection or change request/suggestion until then.

[felixfontein]

There is now an active vote on #245 (comment) happening in #271.

[felixfontein]

I counted votes for #271:

7 x +1 SC votes (felixfontein russoz jamescassell mariolenz markuman gotmax23 Andersson007)
4 x +1 community votes (UnderGreen cybette ecchong leogallego)

Can another SC member please confirm the vote count?

[Andersson007]

@felixfontein i confirm the count. Thanks everyone!

[felixfontein]

Thanks everyone!

[felixfontein]

I think we can close this. community.general adopted this, and other collections can decide whether they want to follow this or something similar as well.