Discussion: Change in process for ansible-test platform updates

[felixfontein]

This thread is for discussing #69.

[felixfontein]

Changes will no longer be announced here in advance

@mattclay would it be possible to still announce these changes here or (even better) in the Ansible forum, but in a more simple form as now? That is, simply announcing that a remote / container image is added / removed, instead of also providing a list of collections and branches to update (which only included AZP-based collections anyway). That would be extremely helpful to avoid CI breakages for collections.

[mattclay]

@felixfontein How would an announcement avoid breaking CI, unless there is a delay between the announcement and the removal?

[felixfontein]

@mattclay if the announcement happens a few days before the changes are merged, one can remove the dead ones ahead of time to avoid breakage.

[mattclay]

@felixfontein We've been working towards eliminating announcements about changes to the devel branch over the past two years. We created the milestone branch specifically to ease the burden on users who want to test against devel, but don't want to deal with spontaneous breakage. The announcements around ansible-test platform changes were some of the last which still followed the process established before the milestone branch existed.

If you'd like to get the best of both devel and milestone branches, I suggest running collection PRs against milestone and perhaps a weekly scheduled job against devel. That will give earlier warning about incompatibilities against devel than you'd get with milestone, while avoiding unexpected issues that could block PRs for collections.

[felixfontein]

I'm not sure why "eliminating announcements about changes to the devel branch" is a desirable goal. I think it's a really bad idea, and it feels very unfriendly especially towards community collection maintainers.

(Also the milestone branch is still not very useful for collection CI since it's not updated when devel's version is bumped, but only ~a month later. This means that you cannot use it in parallel with the new stable-2.x branch if sanity tests changed between the last milestone update and stable-2.x branch point that require changes to the ignore-2.x.txt file, which is used both by stable-2.x and milestone until milestone is bumped again.)

(Also using the milestone branch doesn't help that much, it only reduces the number of days when breakages can happen. You still have to figure out what exactly broke and how to fix it, since there is no human-readable changelog describing the changes since the last milestone bump, and there are no more announcements.)

[Andersson007]

i agree with Felix: the announcements here are very helpful for collection maintainers

[mattclay]

@felixfontein The lack of an update to the milestone branch was an oversight on the part of the core team. We had documented that it was to be updated when creating the new stable branch, but had not done so. I've corrected that. Thanks for bringing it to my attention.

[felixfontein]

@mattclay thanks, that's good to know! The discussion about this in #ansible-devel in March 2022 sounded like the old behavior was intentional (and I wasn't aware so far that it was documented differently).

[mattclay]

See: https://docs.ansible.com/ansible/latest/dev_guide/core_branches_and_tags.html#milestone-branch

The milestone branch is updated to the contents of devel at the end of each development phase.

However, there's a second part which should probably be adjusted:

When a release reaches the Beta 1 milestone, the milestone branch will be updated to the first devel commit after the version number has been increased.

The important part is the branching (and associated devel version bump) which occurs after the end of the third development phase. Although that's close to the first beta release, the beta is usually about a week later.