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

[Ina Panova]

+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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200820/27248aa5/attachment.htm>