[Pulp-dev] problem: version locking plugins to pulpcore

Brian Bouterse bmbouter at redhat.com
Tue Aug 18 20:30:48 UTC 2020

Here's a problem statement(s) and some brainstorming ideas about what could
be done to resolve them. This was discussed today at open floor some also.

# Problem
Pulp plugins version lock to the GA version of pulpcore and don't allow
compatibility with other pulpcore releases. This causes at least two
painful practical problems:

1) users have to wait for all plugins to release before they can upgrade
2) developers have to release everything immediately after pulpcore
releases in an effort to mitigate problem (1).

# Idea

What if pulpcore.plugin had a two-cycle deprecate-then-remove policy? So
instead of making a pulpcore.plugin backwards incompatible change with,
e.g. pulpcore==3.7, we would instead add deprecation warnings to 3.7, and
then remove the code (and deprecation warnings) in 3.8.

Users running a plugin that was using a deprecated codepath or argument
would see these warnings.

Plugins would declare themselves forward compatible with the current GA+1.
So assume pulpcore==3.6 just released, then any plugin releasing afterwards
could declare pulpcore>=3.6,<3.8 instead of the >=3.6,<3.7 they do today.
This assumes plugins are keeping up to date with changes.

Testing wise, the plugin_template would add an additional matrix test that
tests the current GA of a plugin against pulpcore master. This captures the
"one ahead" situation where a user is using a newer version of pulpcore and
the "one back" version of that plugin.

# Feedback

What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200818/c97af120/attachment.htm>

More information about the Pulp-dev mailing list