I think it would be best to simply adjust it so that it aligns with the new dates of ansible-core, i.e.:
ansible-core beta releases get a Ansible alpha release a day later;
ansible-core’s rc releases gets Ansible beta releases a day later;
and ansible-core 2.19.0 GA gets Ansible feature freeze a day later;
Ansible 12.0.0rc1 a week after that;
and 1-2 weeks later 12.0.0 comes out.
WDYT?
And how should we adjust the release schedule at Ansible project 12.0 — Ansible Community Documentation? Simply strike through the dates and add an info box that basically says the above (in nicer wording), and replace the dates once we have more exact ones for ansible-core?
As far as I can see, the ansible-core 2.19 roadmap hasn’t changed yet. I’m not sure if we should change any dates if we don’t have ones from core that we can point to.
At the very least, we should announce both here on the forum and on Bullhorn (maybe simply mentioning the forum post) that we will delay Ansible 12 because of the ansible-core 2.19 release schedule update.
There’s a new delay: according to Core 2.19 beta extended thru June 30, ansible-core 2.19.0 GA will be released on July 21st, instead of June 16th. IMO we should adjust Ansible 12’s schedule once more to match ansible-core’s schedule.
How should we proceed with the PR? (There’s still no PR for the ansible-core roadmap.) Should we wait for an update of the ansible-core roadmap, merge my PR as-is, …?
Since our Roadmap follows that of ansible-core, it would be really great if this would be updated first (hinthint@nitzmahone). Let’s give them a few more days to do it.
Sorry, been buried in, well, you know- I’ll try to have someone push a doc PR this morning or do it myself… Sivel usually handles the roadmap updates, but he’s been out for a few days.
The date shuffle we announced likely puts 2.19.0 on an off-cycle date with the other releases, but that’s OK- gives us a short cycle for 2.19.1, which history shows often ends up releasing early anyway.
In any case, the dates we announced are still good and should be reflected on the roadmap soon. Thanks!
ansible-core 2.19.0rc1 has been released, and we should be releasing a new 12.0.0b4 release soon. (It is mainly waiting for a change in antsibull-build to be reviewed, merged, and a new release of that created.)
Now there’s another thing we need a decision on: as you can read up in Ansible.netcommon broken with Ansible Core 2.19.0 (see the bottom posts), several network collections got a new major release. (So far arista.eos, cisco.ios, cisco.iosxr, cisco.nxos, and junipernetworks.junos have new major releases.) These major releases bump the ansible.netcommon dependency, and besides some bugfixes or features, but seem to have no breaking change. Do we want to include these in Ansible 12.0.0? While we wanted to not have breaking changes if we can avoid it for Ansible 12.0.0, which usually means no major version bump for already included collections, these could be acceptable since they do not actually contain breaking changes. @SteeringCommittee what do you think?
It possible, I would prefer if the other network collections did not have additional major versions. We are a month past the scheduled feature freeze and have already modified our policies, schedules, and tooling to accommodate the network collections once. I would vote to make another exception if absolutely necessary, but it would be great if we could work with the network collection maintainers to find another solution so we can simply update the networking collections to the latest minor version.
Well, I guess I didn’t read closely enough (I was a bit rushed when I first looked at this — mea culpa). Major version bumps have already happened. I started reading at Ansible.netcommon broken with Ansible Core 2.19.0 - #22 by KB-perByte from @KB-perByte from last week about the planned major release bumps but didn’t immediately realize that they had already happened — despite feedback from other steering committee members. It sounds like this was a miscommunication, but I find it frustrating that it seems our policies are not being followed. This now creates extra work for the Ansible release managers, as we have to manually reset the ansible-12.build file to accommodate the major version bumps in these collections that occurred after the beta1 release when the feature freeze started.
To be explicit, I do support including these releases, despite my reservations. What do other @SteeringCommittee members and @release-managers think? As @felixfontein said, we were supposed to release Ansible 12.0.0b4 this week, so it would be great to reach a consensus about whether to include these newly released collections soon.
