[Pulp-dev] problem: version locking plugins to pulpcore
bmbouter at redhat.com
Fri Aug 28 16:38:56 UTC 2020
After a bit of discussion today at the open floor, the proposal is to
introduce this with pulpcore 3.7. Then all plugins would enable this by
doing two things:
* Declaring their pulpcore dependency as pulpcore>=3.7,<3.9 with the 3.7
compatible plugin release
* Enabling the additional CI test provided by
https://pulp.plan.io/issues/7411 as soon as its available
This is organized into this epic https://pulp.plan.io/issues/7416 which has
the following 3 stories:
Any feedback or concerns are welcome. I'd like to bring these onto the
sprint at Tuesday's open floor. I've added them to the agenda.
On Thu, Aug 20, 2020 at 1:41 PM Ina Panova <ipanova at redhat.com> wrote:
> +1 to the idea. It will definitely improve user experience.
> Ina Panova
> Senior Software Engineer| Pulp| Red Hat Inc.
> "Do not go where the path may lead,
> go instead where there is no path and leave a trail."
> On Wed, Aug 19, 2020 at 12:21 PM Tatiana Tereshchenko <ttereshc at redhat.com>
>> +1 to have one Y release with depreciation warnings before actually
>> removing the code or introduce any backward incompatible change.
>> On Wed, Aug 19, 2020 at 10:09 AM Matthias Dellweg <mdellweg at redhat.com>
>>> 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>
>>> > 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
>>> > # 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
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev