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

[Brian Bouterse]

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
anything.
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>