<div dir="ltr"><div>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></div><div><br></div><div># Problem</div><div>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:</div><div><br></div><div>1) users have to wait for all plugins to release before they can upgrade anything.</div><div>2) developers have to release everything immediately after pulpcore releases in an effort to mitigate problem (1).</div><div><br></div><div># Idea</div><div><br></div><div>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.</div><div><br></div><div>Users running a plugin that was using a deprecated codepath or argument would see these warnings.</div><div><br></div><div>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></div><div><br></div><div>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.</div><div><br></div><div># Feedback</div><div><br></div><div>What do you think?</div><div><br></div></div>