[Pulp-dev] Raising the pulpcore requirement for plugins

Brian Bouterse bmbouter at redhat.com
Mon Oct 12 20:40:09 UTC 2020

Hi Quirin,

Apologies for the long delay. Thank you for bringing this up. I wrote some
responses inline with what I believe to be true. More questions are welcome!

On Wed, Sep 30, 2020 at 3:51 AM Quirin Pamp <pamp at atix.de> wrote:

> So far, I have been mindlessly raising the pulpcore requirement by one Y
> version with each Y version release of pulp_deb. So, for example, The
> release of pulp_deb 2.5.0b1 was compatible with 'pulpcore>=3.5,<3.6', and
> the 2.6.0b1 release was compatible with 'pulpcore>=3.6,<3.7'.
> I have been talking to x9c4 about this, since he pointed out that there
> really wasn't any reason to automatically raise the floor on pulpcore if
> there are no breaking changes. For example, it might have been fine for
> 2.5.0b1 to have a dependency of 'pulpcore>=3.5,<3.6' and for 2.6.0b1 to
> switch that to 'pulpcore>=3.5,<3.7', leaving the floor of the range
> untouched (not sure if there actually were no breaking changes with those
> particular versions, it is just intended as an example).
Yes this is the case. For example pulp-certguard hasn't experienced a
breaking change since 3.3, so it's floor version even for the latest
release declares compatibility all the way back to 3.3 (and forward through
3.8) https://github.com/pulp/pulp-certguard/blob/1.0.3/requirements.txt#L2

> x9c4 also argued that it might be a good idea to raise the floor
> requirement with the introduction of a breaking change (and not at the time
> of creating the release branch).
I agree with this, if a plugin makes a change which would require it to
have a specific version of pulpcore.plugin, along with the plugin's change
it should raise the floor version. If this is done at development time
correctly at release time the "floor" would never be raised.

> Both suggestions make sense to me, but they do not seem to reflect the
> current workflow for most plugins right now (I also don't feel very
> comfortable I know how to recognize breaking changes, making me want to
> keep on mindlessly raising the floor to be on the safe side). The release
> script is built in a way that suggests both upper and lower pulpcore range
> should be set at the time when the release branch is created. With all of
> this in mind, here are some questions I have for the community:
At release time the upper limit is specified to ensure a much later
pulpcore release won't end up breaking user installs. The floor however I
expect to be kept in source control at all times. For example, 3.3 as the
minimum for pulp-certguard is shown on master always:
https://github.com/pulp/pulp-certguard/blob/master/requirements.txt#L2 The
idea is that the floor declares actual compatability, and during
development there is no upper limit to always have the CI evaluate the
forward compatibility with pulpcore, and only at release time do you say
"oh actually we're only compatible as far as pulpcore~=x.y.0".

> 1) Are there any current best practice recommendations how to raise the
> floor on the pulpcore requirement for plugins?
Raise it at development time when a plugin actually requires a newer
pulpcore.plugin version.

> 2) Does it make sense to raise the floor when a breaking change is
> introduced, rather than when the release branch is created? (This might
> give a false sense of security when cherry-picking things from after the
> raising of the floor.)
Yes, I recommend at development time, when the plugin's change is made.

> 3) Other than reading the "Deprecations and Removals", how does one
> recognize when a breaking change in pulpcore needs me to raise the floor?
> (Especially now with the new 2 Y-version deprecation cycle, some more
> pointers/examples on how to use this in practice would be good.) Is it just
> a matter of running the test suite against each pulpcore version that I am
> declaring compatibility with?
The idea (to me) is that the functional tests will tell us. What we don't
test, we can't be sure works. Right now @dkliban is extending the
plugin_template to add a nightly test to the CI of each plugin which tests
the GA of a current plugin against the unreleased next version of pulpcore.
If your plugin has all the tests you care about then this CI run will point
out places where your plugin is not compatible with the future pulpcore.
This tells you either now is the time for you to port, or perhaps the
pulpcore folks broke something they didn't intend to (without the proper
deprecation length). The ticket is here: https://pulp.plan.io/issues/7411
He ran into one or two issues getting it working, but I believe he's
resolving those. Getting this rolled out to all plugins I think is key to
sorting these problems out.

> Any thoughts and hints are appreciated!
> Kind regards,
> Quirin Pamp (quba42)
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20201012/9afa1b82/attachment.htm>

More information about the Pulp-dev mailing list