If we make backwards incompatible changes to the plugin API every 5th release, these changes would happen about every 7 months. I like this plan, but maybe we should go with every 4th release?
Maybe you can specify the version the plugin should be compatible with and all deprecations that are found for that release will be breaking CI. But then we should still show the ones you can already know of.
I propose we make the next pulpcore release to contain breaking plugin API changes to be 3.20. We don’t need a “forever” change in policy before we’ve tried this idea. If we can agree on 3.20 it will give these benefits:
- Plugins can declare their next releases as compatible with <3.20
- We can try before committing to something forever
What sorts of CI changes do we need to have the release automation declare 3.20 instead of 3.next?
+1, 3.20 is basically 3 releases ahead which is not too short, not too long period to try it out.
To my knowledge the automation does not set requirements, it’s done manually by a plugin maintainer.
With all positive feedback and no negative feedback heard I’ve written this blog post to make it an official thing: https://github.com/pulp/pulpproject.org/pull/399
Additionally, the Roles work has plugin API deprecations and eventual removals as part of it and that is declaring in those deprecations they will be removed in 3.20.
1 Like
+1 to this. I’d still discuss though every which release there will be breaking changes in plugin API.
At the pulpcore meeting we decided to try this. This has been announced publicly here: Increasing Pulpcore Compatibility with Plugin Versions | software repository management
When we are preparing the pulpcore==3.20 release, we’ll need to decide what the next “plugin API breaking change will be”, e.g. pulpcore 3.24 or 3.25.
I think it’s safe to say the “bundling of all breaking plugin API changes into one release” has successfully reduced unnecessary plugin compat releases. It’s time for us to pick the next “plugin API breaking change release” after 3.20.
I propose we select pulpcore==3.25 because that would be roughly 6-7 months from now. I see a lot of benefit of plugins not having to all release to have declare forward comparability with pulpcore, and I see little benefit to introducing plugin API breaking changes sooner than 6-7 months.
What do you think we should do?
2 Likes
Plus one for the 3.25 idea and more importantly on the “every minor version divisible by 5” idea, because that is rather easy to remember. Also roughly half a year sounds like a good balance between managing the churn with breaking changes and the resentment for missing the window with any particular change.
Another question that came to my mind: When do we start declaring deprecations for the new breaking release? e.g. I think, we should not remove anything with 3.20 that has not been deprecated with 3.19 at least. Should we extend that to 3.18 (as in 2 releases back from the breaking one)?
Ok, since pulpcore 3.19 is now out, and the dreaded breaking 3.20 is coming up next, I would like to ask the following:
When doing a plugin Y-release now, (assuming the plugin is not experiencing any deprecation warnings), should that plugin declare compatibility up to pulpcore<3.25 or up to pulpcore<3.20?
If it is the latter (i.e. there can be breaking changes in pulpcore 3.20 that have not already been advertised as deprecations), I suppose this means, that once pulpcore 3.20 releases, all plugins will need to check for breakage, fix them, and do a compatibility Y-release. This would mean there would be a period (however short) where pulpcore 3.20 is released, but has no compatible plugins. More importantly there would be a probably not so short period, where not all plugins are compatible with 3.20. Thoughts, corrections, additions?
EDIT: I guess a somewhat bumpy 3.20 release is tolerable since the breaking releases are only expected every 6 months or so going forward.
That basically represents the other end of my question
To be fair, that is kind of only asserting the original policy, that we cannot remove things without deprecating them in an earlier release.
I propose we select pulpcore==3.25 because that would be roughly 6-7 months from now. I see a lot of benefit of plugins not having to all release to have declare forward comparability with pulpcore, and I see little benefit to introducing plugin API breaking changes sooner than 6-7 months.
I don’t think that matches our actual cadence.
3.18 → 3.19 = 7 weeks
3.17 → 3.18 = 9 weeks (that includes winter shutdown)
3.16 → 3.17 = 9 weeks
3.15 → 3.16 = 5 weeks
3.14 → 3.15 = 9 weeks
We’re currently at nearly 8 months since 3.15, and I don’t see 3.20 releasing any sooner than 6-8 weeks from now, so that will be 9-10 months between breaking changes. So if we change nothing else about our process that would be roughly what it would be going forwards, too - not 6-7 months between breaking changes.
If we like our current release cadence (and I mostly do), then it ought to be every 3 releases, because that will put us at 6-7 months between breaking changes. Or maybe every 4, which feels like a nicer number - but 5 is definitely too many IMO.
I tend to agree. Very often we postpone release date due to various reasons and it is rare when we release on time.
Well, i think the “half a year” was just a convenient coincidence. Having the deprecations living for a little longer is probably not a big deal and should not hold us back in terms of innovation. We should stick to a rebuild-side-by-side model for big refactoring changes anyway.
Having said that, i still vote for 5 releases.
@dralley thanks for the analysis; it’s more accurate than my guessing for sure.
Even with it being maybe 9-10 months, I’m still in favor of 3.25 as the next one because I think we benefit from a longer compatibility cycle. I’m also in favor of “every release divisible by 5” so 3.25, 3.30, 3.35, … , etc because it’s simple.
1 Like
I feel like we ought to build in an assumption, then, that the releases with breaking changes (e.g. 3.20) will take significantly longer - ~10-16 weeks instead of ~8. Because otherwise we’re just not going to be able to pay down the technical debt at a reasonable pace - especially if we have to maintain parallel implementations of massive bits of core functionality (which I’m a bit skeptical of us doing, because it feels like a great way to unintentionally introduce new bugs accidentally, or result in failing to fix bugs properly in both places, or spend an inordinate amount of time writing different patches for each side).
The extra time would also reduce the need for said parallel implementations.
Just to followup, through the pulpcore meetings it’s been established that 3.25 is the “next” breaking change release.
2 Likes
Note that we may have to take into consideration Django LTS lifecycles. If we can only upgrade Django in the breaking changes releases, then that needs to be aligned with product versions and release cycles.
For example Django 3.2 LTS support ends in April 2024. If pulpcore 3.25 doesn’t line up with a migration to Django 4.2 then downstream releases will be stuck on unsupported Django for a long time.
I see that Django 4.1 is scheduled to release on Aug 2022 and 4.2 LTS is scheduled to release on April 2023. If pulpcore 3.25 comes out after April 2023 then I’m +1 on upgrading to Django 4.2 LTS then, but if it comes out before we should upgrade to Django 4.1 and the upgrade to Django 4.2 after that (3.30 or have a shorter plugin API break declaration). Anyways, basically we should be upgrading Django during breaking change pulpcore releases, and we likely should upgrade to 4.1+ in pulpcore 3.25.
@dralley and others how does ^ match up with what you were thinking?
Sounds fine, just be aware that 4.1 is only supported for 6 months, so we really can’t stay on that release.