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.
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).
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.
What do you think?