This is something I’ve noticed, but I don’t have a good answer to. Historically we’ve seen that there’s always a tension between making changes in core and plugins being able to follow. I could try to make a list, but I think most can imagine it. If not, here’s the latest discussion about it:
Now my first question is: should we find some standard way and if so, how?
I’ve thought about some developer release notes similar to how we have user release notes, but I’m not sure how people will keep up to date with that. The benefit is that we have a nice historic overview so even plugin authors who’ve skipped a release or two can easily find the information. The downside is that if we place such a list on the website you don’t get notifications.
Another thought I had was to create a post per release on Discourse, perhaps even on a separate forum or topic so you can easily search for it and be subscribed.
We have the same problem on the Pulp side, and at least once we tried with a discourse post. The reception by one community member was very positive. But it seems we didn’t keep up with that.
I will add some thoughts from my recent deprecations clean up.
It would appear that marking some code path as deprecated doesn’t necessarily mean plugin authors will modify it. To actually clean up the deprecated code without breaking plugins I actually needed to open multiple PRs to various plugins who have ignored the deprecation warnings for multiple releases.
It also delays code changes and requires someone to remember to eventually clean up the core (I just deleted some code that was marked for removal in versions as old as 2.3).
For smaller changes that are easy to explain and perform, I think we should stop deprecating them and move to dropping/modifying code directly with a warning to developers. Opening PRs to repos in the Foreman organization for fixing such changes in parallel would be appreciated and allow us to move faster in general.
Larger changes such as dropping functionality should probably continue to use a deprecation warning, potentially with user-facing notification, and be cleaned up after a release or two.
Deprecation warnings are really great in combination with some CI test (in the plugin) that will flag them (fail if there are deprecation warnings against the next release). Otherwise plugin authors will simply not see the deprecation warnings in time unless they happen to be working on the plugin at the right moment. Not sure how hard it is to create a test like that (that can easily be added to the various plugins).
Ruby deprecation warnings should fail any tests reaching them (unless they were permitted using https://github.com/domcleal/as_deprecation_tracker), but unfortunately most plugins have very minimal test coverage, or tests that are constantly red for months (see for example Plugins [Jenkins]).
With JS the situation is even worse, since plugins run the tests from inside the plugin and often mock out a large chunk of the core code (e.g. the whole redux store and actions) so they won’t fail even after code has been dropped sometimes.
Maybe what is really needed then is a plugin test coverage drive.
If many plugins suffer from this, there should be some synergies in working on it for all of them…
Another thought I had was to create a post per release on Discourse, perhaps even on a separate forum or topic so you can easily search for it and be subscribed.
I like this idea. Sometimes it is hard to keep up with everything that is going on in core or one is busy with a different projects and things get lost along the way. Creating a post in a dedicated location on discourse seems like something that can be done with reasonable effort.
What works for me when I find time I would post the testweek post and then build all my plugins and test the package scratchbuilds against the RC. However, last time I was not able to do this, thus the confusion later on when I started fixing things pretty late in the RC phase.
I was thinking about this again and this is what came to my mind: There is a label functionality in github, so maybe PRs with breaking changes could be labelled as such. Also, the commit message could contain something like [BREAKING CHANGE], such that (plugin) developers can easily filter for breaking changes in core.
