The Core team announced that the Dec 25/Jan 1 ansible-core release window of 2.16.2 would be delayed. I assume we’ll want to make the same adjustment for the ansible community package 9.2.0 release. I’m not sure if the @SteeringCommittee should vote on this. What do you all think?
Use [Vote ended on 2023-12-04] Release schedule for holiday releases - #22 by mariolenz to vote! The vote ends on 2023-12-04.
Last year we did have a vote.
The current release schedule is approximately every four weeks if changes to collections have been made or to align to a later ansible-core-2.16.x. Since there will probably at least some changes to the collections, I guess we should have a vote on this.
But I don’t insist if the rest of the @SteeringCommittee thinks otherwise.
We did adjust the release schedule around RC/GA so that Ansible 9.x.0 is aligned to ansible-core 2.16.x, at least starting with x = 1 (since ansible-core 2.16.0 is aligned with 9.0.0b1 more isn’t really possible). So if we want to keep that alignment, we should again delay Ansible 9.2.0 until ansible-core 2.16.2 comes out, i.e. until end of January.
Since this will likely happen every year from now on, we could also vote on a more generic proposal that we generally want to align Ansible y.x.0 with ansible-core 2.(y+7).x for x >= 1 for as long as Ansible y is not EOL. Then we don’t have to discuss and vote on this every year.
Keep in mind the reason core is doing this is to allow for the various end-of-year time off/breaks a lot of people take. My un-steering opinion is that we should follow that pattern unless there is some urgent reason not to.
Seems like an easy way to get used to voting here … it seems uncontroversial 
The roadmap says:
Ansible 9.x minor releases will occur approximately every four weeks if changes to collections have been made or to align to a later ansible-core-2.16.x.
Maybe we should remove the “if changes to collections have been made” and just say we’re aligning with ansible-core 2.16. This way, the next time ansible-core announces a delay we could just announce to follow their lead in The Bullhorn without a lot of discussion and voting. Or is it too late to change this on the roadmap?
For Ansible 10 we should just start like this when we create the roadmap.
I guess we can make changes in the roadmap this time with a detailed explanation in the Bullhorn. It will be easier for people to find and follow the dates of next release (since we always point the roadmap to follow for the upcoming releases dates).
PROPOSAL:
Starting in 2024, the Ansible community package release schedule will follow the Ansible Core release schedule, including delays for the winter holidays. This means Ansible releases happen every four weeks through most of the year, but release dates may be delayed in November and December so community maintainers can celebrate and take time away from their responsibilities. Instead of addressing each delay individually as it comes up, we will plan to follow the holiday schedule as announced by the Core team.
I would keep it a bit shorter and not mention “so community maintainers can celebrate and take time away from their responsibilities”:
Starting in 2024, the Ansible community package release schedule will follow the Ansible Core release schedule, including (for example) delays for the winter holidays. This means Ansible releases happen every four weeks through most of the year, but release dates may be delayed when Ansible Core release is.
Would “December / January holidays” or “end of year holidays” make more sense for people in the southern hemisphere?
I think you’re right, I’ve removed “the winter” from my proposal.
Mario created a PR for this: [WIP] Ansible 9: Follow ansible-core more closely by mariolenz · Pull Request #856 · ansible/ansible-documentation · GitHub
Please take a look! If nobody objects, let’s have a vote on this soon.
I’ve tried to phrase it more generically here.
Maybe you all should have a look at it. If this sounds OK, I would remove the [WIP]. If not, please tell me to to improve it 
Even if you agree to this change, we still have to agree on what we want to publish in The Bullhorn, though.
What do you think of:
From now on, the Ansible community package release schedule will follow the Ansible Core release schedule, including (for example) delays for holidays. This means Ansible releases happen every four weeks through most of the year, but release dates may be delayed when Ansible Core release is.
For the upcoming holiday season this means that there will be no Ansible release in early January, but instead on January 30th.
for The Bullhorn?
I would say “from now on”, not “starting in 2024”. Apart from this LGTM.
I don’t mind changing it, it’s basically equivalent, since the next 9.1.0 release is on December 5th, and four weeks after that is already in 2024 (Edit: just changed it.)
If nobody objects until the beginning of next week, let’s start a vote on this.
Good idea. Proposal for a vote:
Change the Ansible 9 roadmap (specifically: the timing of minor releases) as proposed in Ansible 9: Follow ansible-core more closely so we do not have to discuss what to do every time when ansible-core delays a release.
Announce the change of our release policy on Bullhorn with:
From now on, the Ansible community package release schedule will follow the Ansible Core release schedule, including (for example) delays for holidays. This means Ansible releases happen every four weeks through most of the year, but release dates may be delayed when Ansible Core release is.
For the upcoming holiday season this means that there will be no Ansible release in early January, but instead on January 30th.
If no one objects, I would start a vote with above proposal on Tuesday 2023-11-28 and let it end 2023-12-05.
How about ending the vote on December 4th, and already starting already tomorrow, so that the result can be properly mentioned in the December 5th release without having to close the vote earlier on December 5th?