+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
