our usual practice is to start making breaking changes as soon as we branch out core repository. Thing is, plugin maintainers are still ironing out latest changes during the release candidates cycle and finalizing testing.
Pushing breaking changes in the early stage of finalizing makes it harder for plugin maintainers as incompatible commits (with the stable / branched core version) are merged into develop. I think that we can afford 2-3 weeks delay for those breaking changes in our 3 months development cycle.
I feel your pain and I’m sorry for causing it. But I do not agree here.
We have 3 months in devel cycle, last month is usually for stabilization and pushing last-minute changes, so that gives you 2 months for breking changes, if you take out another period it will leave you with only 1,5 month for actuall development of bigger features and with the usual speed of reviews that is not enough to get bigger changes in.
Current Rails 6 upgrade is a good example, as it will probably require some changes in plugins as well, that means we need to get it done ASAP so plugins have as much time as possible from the devel cycle to react and make the necessary changes. SO I believe this should be done in core at least mid devel cycle.
I agree we should not break the about to be released plugins, but I’d suggest this can be as easy as branch your plugin stable version with core and test it only against stable Foreman. You’d need then cherry-pick changes that should get in the stable version of the plugin, but I believe it is the correct way, as that opens up door for breaking changes in the plugins as well. Which is much easier to synchronize, when the devel cycles would be in sync.
I think doing breaking changes shortly after branching is almost unavoidable, as that is the best time to ensure the period of testing for this change is as long as possible.
However, I think what we should do is try to communicate and prepare those changes better.
Let’s take https://github.com/theforeman/foreman/pull/8946 as an example (sorry Ondrej, really not picking on you, but this is a good example by which we can try to improve the process!).
The change was proposed Tuesday evening and merged Wednesday morning, essentially giving zero time for plugins to catch up.
It seems it was know that this will break plugins, as related PRs against foreman_puppet and foreman_discovery were opened shortly after the merge, but it was unclear whether the proposed changes make the plugin non-compatible with stable Foreman versions or not (looking at https://github.com/theforeman/foreman-packaging/pull/7338, I think the answer is “not compatible”).
How about the following process:
propose a breaking change (via a PR)
once there is rough agreement that this will go in, try to verify whether this breaks any of the current plugins
if this breaks any plugins, notify their maintainers (and optionally propose fixes)
once plugins acknowledge that they are aware of the upcoming breakage (and optionally have merged the fixes), merge the breaking change
This should ensure that
maintainers are aware that there is a breaking change coming (I think this time they weren’t)
there is a chance to see if the plugin change itself is backward compatible, or whether this will require further planing of plugin branching
