[vote open until 2025-04-16] Make Ansible 11 a "LTS" (similar to Ansible 9)?

Assuming that Data Tagging is merged for ansible-core 2.19 (which will be the core of Ansible 12), migration of existing roles and playbooks to ansible-core 2.19 and thus Ansible 12 will require a lot of work since there are a lot of existing (mostly bad and common) behaviors that will stop working. To give users more time to migrate, how about extending Ansible 11’s lifetime for another 6 months, similar to what we did with Ansible 9 (the last version to support Python 2.7 and 3.6)?

6 Likes

CC @release-managers since this means more work for us :wink:

1 Like

This sounds good to me. That said, I am not involved in packaging releases. I think the folks who do work on the releases should have the final say.

I’m not sure if this will be really necessary.

On the other hand, I think that the automation to do releases is pretty good (thx @felixfontein!) . We can handle it, so I won’t object.

This makes sense to me as well.

For the record: Maintain Ansible 9 for longer than 6 months

1 Like

SGTM, thanks for bringing this up!

According to ansible-core 2.19 release schedule update ansible-core 2.19 will have Data Tagging (and will be delayed w.r.t. its original schedule, on which the Ansible 12 release is based). I still think having a Ansible 11 “LTS” with new releases for ~6 additional months (basically until Ansible 13 comes out) is a good idea.

Are there objections, or further needs to discuss this? Or should we start a vote on this without further discussion?

1 Like

I think a vote is OK. After all, nobody stepped up so far who was deadly against it.

However, since it looked for some time that DT might not make it into 2.19 we should make this explicit. Just to make sure in case something really bad happens and core changes their mind.

So let’s vote on making Ansible 11 an “LTS” release if DT makes it into ansible-core 2.19 yes / no.

That way, if core changes their mind again we wouldn’t have the burden to maintain 11 for longer without a good reason, or start another vote to revert this decision.

Does this sound OK?

1 Like

Sounds good to me. (Still not 20 characters :wink: )

The following vote will be open until April 16th during the weekly community meeting.

Note that the “Yes” vote is coupled to the Data Tagging PR being merged. If the PR is not merged into ansible-core 2.19.0, or removed later on before 2.19.0 is released, Ansible 11 will become End of Life once Ansible 12 is out no matter how this vote concludes.

Should Ansible 11’s lifetime be extended by roughly 6 months until Ansible 13 is out, assuming DT is included in ansible-core 2.19.0? (Steering Committee vote)
  • Yes, assuming that Data Tagging is part of ansible-core 2.19.0, Ansible 11 should only become EOL once Ansible 13 is out. This means that Ansible 11 and 12 will be released in parallel until then.
  • No, Ansible 11 should become EOL once Ansible 12 is out, as originally planned.
0 voters
Should Ansible 11’s lifetime be extended by roughly 6 months until Ansible 13 is out, assuming DT is included in ansible-core 2.19.0? (Community vote)
  • Yes, assuming that Data Tagging is part of ansible-core 2.19.0, Ansible 11 should only become EOL once Ansible 13 is out. This means that Ansible 11 and 12 will be released in parallel until then.
  • No, Ansible 11 should become EOL once Ansible 12 is out, as originally planned.
0 voters
1 Like

I voted yes, but it’d be good to have a draft ansible-documentation PR along with this vote that we can merge if/when if data tagging ends up making it in.

1 Like

Good idea, I’ve created the PR here: [WIP] Announce Ansible 11 lifetime extension by felixfontein · Pull Request #2491 · ansible/ansible-documentation · GitHub
In the PR I wrote that it should only be merged once this vote is accepted and ansible-core 2.19.0 rc1 is out. I guess from that point on it will be quite unlikely that Data Tagging will be removed again before 2.19.0 GA comes out.

2 Likes