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

[Brian Bouterse]

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:
* https://pulp.plan.io/issues/7411
* https://pulp.plan.io/issues/7413
* https://pulp.plan.io/issues/7415

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.
> --------
> Regards,
>
> 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>
> wrote:
>
>> +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
>>>
>>> _______________________________________________
>> 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/20200828/51a8fd0c/attachment.htm>