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

[Tatiana Tereshchenko]

+1 to have one Y release with depreciation warnings before actually
removing the code or introduce any backward incompatible change.

Tanya

On Wed, Aug 19, 2020 at 10:09 AM Matthias Dellweg <mdellweg at redhat.com>
wrote:

> 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
>
>
> _______________________________________________
> 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/20200819/afac709d/attachment.htm>