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

[Matthias Dellweg]

This sounds pretty much the same as i had in mind. Thank you for writing it up!
One concern inline:

On Tue, Aug 18, 2020 at 10:31 PM Brian Bouterse <bmbouter at redhat.com> wrote:
>
> 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.
As the plugins last version isn't the one changing here, but pulpcore
is, i think pulpcore needed to be tested (maybe only daily; we can
measure by the amount of necessary reverts) with a wisely chosen
subset of plugins. Starting with file and certguard would be easy.
>
> # Feedback
>
> What do you think?
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev