At pulpcon 2021 the problem came up that the N+1 forward compatibility with pulpcore causes a lot of unnecessary plugin releases. These are unnecessary in the sense that they are only required to bump the upper bound of compatibility.
As a problem example, here’s a pulp_file commit for a pulp_file release that sets the upper bound at release time.
There was a session at pulpcon discussing ideas for this and I’ll try to summarize them.
Merge breaking changes in the plugin API very early in the pulpcore release cycle. So if we are removing this in pulpcore 3.20, we should be removing all of those things say 5-7 calendar days after we release pulpcore 3.19. This gives plugin writers a long time to update their code for compatibility.
Update the CI to show that there are deprecations emitted as each plugin runs its test suite. The goal here is to make it as clear as possible to plugin writers their plugin is not compatible with the upcoming pulpcore release.
This approach would have say every 3 pulpcore releases or perhaps everyone divisible evenly by 5, 3.20, 3.25, etc allow breaking changes. This would allow plugins to declare compatibility up until the next “3rd” or “5th” release which would reduce the number of plugin releases significantly.
I believe this idea had the most consensus ^.
In this case, when we wanted to introduce breaking plugin API changes we would be releasing Pulp 4. At least one concern resonated especially with me. @dralley pointed out that if we left the api at /pulp/api/v3/ it would be confusing so we’d have /pulp/api/v4/. Even if upgrading is easy, it’s hard to ask all users to switch from using /pulp/api/v3/ to /pulp/api/v4/ unless /pulp/api/v4/ is meaningfully a new, backwards incompatible API.