<div dir="ltr"><div>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:</div><div><br></div><div>* Declaring their pulpcore dependency as pulpcore>=3.7,<3.9 with the 3.7 compatible plugin release</div><div>* Enabling the additional CI test provided by <a href="https://pulp.plan.io/issues/7411">https://pulp.plan.io/issues/7411</a> as soon as its available</div><div><br></div><div>This is organized into this epic <a href="https://pulp.plan.io/issues/7416">https://pulp.plan.io/issues/7416</a> which has the following 3 stories:</div><div>* <a href="https://pulp.plan.io/issues/7411">https://pulp.plan.io/issues/7411</a></div><div>* <a href="https://pulp.plan.io/issues/7413">https://pulp.plan.io/issues/7413</a></div><div>* <a href="https://pulp.plan.io/issues/7415">https://pulp.plan.io/issues/7415</a></div><div><br></div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 20, 2020 at 1:41 PM Ina Panova <<a href="mailto:ipanova@redhat.com">ipanova@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"><div dir="ltr">+1 to the idea. It will definitely improve user experience.<br><div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr">--------<br>Regards,<br><br>Ina Panova<br>Senior Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 19, 2020 at 12:21 PM Tatiana Tereshchenko <<a href="mailto:ttereshc@redhat.com" target="_blank">ttereshc@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"><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" target="_blank">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>
_______________________________________________<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>
</blockquote></div>
_______________________________________________<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>
</blockquote></div>