+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 <ttere...@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 <mdell...@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 <bmbou...@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@redhat.com >> > https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev