<div dir="ltr">+1 to have one Y release with depreciation warnings before actually removing the code or introduce any backward incompatible change.<br><div><br></div><div>Tanya</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 19, 2020 at 10:09 AM Matthias Dellweg <<a href="mailto:mdellweg@redhat.com">mdellweg@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This sounds pretty much the same as i had in mind. Thank you for writing it up!<br>
One concern inline:<br>
<br>
On Tue, Aug 18, 2020 at 10:31 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@redhat.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> # Problem<br>
> 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:<br>
><br>
> 1) users have to wait for all plugins to release before they can upgrade anything.<br>
> 2) developers have to release everything immediately after pulpcore releases in an effort to mitigate problem (1).<br>
><br>
> # Idea<br>
><br>
> 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.<br>
><br>
> Users running a plugin that was using a deprecated codepath or argument would see these warnings.<br>
><br>
> 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.<br>
><br>
> 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.<br>
As the plugins last version isn't the one changing here, but pulpcore<br>
is, i think pulpcore needed to be tested (maybe only daily; we can<br>
measure by the amount of necessary reverts) with a wisely chosen<br>
subset of plugins. Starting with file and certguard would be easy.<br>
><br>
> # Feedback<br>
><br>
> What do you think?<br>
><br>
> _______________________________________________<br>
> Pulp-dev mailing list<br>
> <a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
<br>
<br>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
<br>
</blockquote></div>