-
Notifications
You must be signed in to change notification settings - Fork 9
[Vote ended on 2022-05-01] Schedule community.kubernetes for removal in Ansible 6 or Ansible 7 #93
Comments
2, then 1 |
Ansible 4.2 was released Jun 30, 2021. Even without an explicit version cut-off, that's nearly a year for users to react if we remove the collection from Ansible 6.
I slightly prefer 1 over 2. But 2 would be OK for me. |
You're right, the official release date is 2021-06-29 (I guess the release happened later in a timezone so it shows up as 2021-06-30 for us :) ). Since Ansible 6 GA is planned for 2022-06-21, this will be ~1.5 years vs. ~1 year. I'll update the issue. |
I also slightly prefer 1) but am fine with 2) Main reason for 1) is to not have to think about this again, and it's already been a long time, but Felix said, there is little downside to 2) without much in the way of content to break. |
+1 for 1.) |
Prefer 1, would be okay with 2. |
Strongly prefer 1, then 2. |
1, 2 |
I also prefer 1. Less is more sometimes. But we also should respect the users, so 2 is fine too. |
2, then 1, if only because that collection was pretty popular and I think until people see an official deprecation, they might not begin work to move to the new naming (except for those of us who follow development more closely). 1 wouldn't be too outlandish but I like the precedent of an official deprecation announced a release in advance for a removal. It's not so bad, of course, considering that as a stopgap someone could still install the collection manually if it's gone, but that process should be highlighted in the release notes if #1 is chosen. |
1 or 2, no preference |
Users had ~1 year to be aware of the change. I think one more year as a deadline is enough. I vote 1. Then 2 but a hard NO on 3. |
Counting votes:
This means that 1 has a total of 9 SC votes and 3 community votes, 2 has a total of 8 SC votes and 3 community votes, and 7 SC votes and 2 comunity votes prefer 1, while 1 SC vote and 1 community vote prefer 2. I think it's pretty clear that 1 is accepted:
Once someone from SC can confirm this vote count, this is accepted. |
Confirming the count matches @felixfontein's count, counted a few times (this feels harder than it should be!). Someone suggested we try the new GitHub Discussions poll feature for vote counts, I think that's a good idea. |
Regarding voting: if you want to use something else, please create a discussion topic for that so we can properly discuss it :) |
PR to remove community.kubernetes from Ansible 6: ansible-community/ansible-build-data#116 |
Summary
community.kubernetes 2.0.0
is mostly empty, it contains deprecated redirects tokubernetes.core
. We announced in Ansible 4.2 (changelog fragment) thatcommunity.kubernetes
will be removed eventually from Ansible, but we did not provide an explicit version cut-off. (See ansible-community/community-topics#22 for the general discussion.)Let's vote on three (mutually exclusive) proposals:
Remove
community.kubernetes
from Ansible 6.Announce removal of
community.kubernetes
from Ansible 7 in Ansible 6.0.0.Do not remove, or announce removal, of community.kubernetes from
ansible
for now. (ie, no change.)The main con for 1), and pro for 2), is that we give users a longer deprecation period (~1.5 years instead of ~1 year) to update their FQCNs to kubernetes.core. Still including community.kubernetes does not really hurt, since there is almost no content.
Please vote by writing the option (1, 2 or 3) you like. You can also specify multiple options in order of preference (like: 2, 1, 3 if you prefer 2, but if there is no majority to it, prefer 1, and if there's no majority for it either, 3).
I've set the deadline to in one week, since on May 3rd the second Ansible 6 alpha will be released. If we want to remove something from Ansible 6, it would be good to do that from the alpha releases as early as possible.
CC @ansible-community/steering-committee
The text was updated successfully, but these errors were encountered: