When discussing this recently, there was another case we ran into: Suppose you add a patch to a plugin, that requires an (already merged, but) not yet released change to pulpcore, then you cannot bump the version requirement to the next pulpcore version right away. So the result of the discussion now sounds like this:
1) plugins on their main branch depend on pulpcore only with a lower bound. The upper bound is only available on the very commit that will be tagged for the release, and that will adhere to the deprecation policy (as in "<3.y+2"). 2) the pulpcores dependencies lower bound should reflect the actual requirement at all times. That means the plugin should bump this lower bound whenever it introduces a change that needs a bump in the pulpcore version. 2.1 If the needed pulpcore version is released, pick that one. 2.2 If the needed pulpcore version is not released (but the change being merged will land in the next y-Release), require the current development version of pulpcore (e.g. >=3.8.0.dev) 3) Upon releasing the plugin, do not touch the lower bound of the required pulpcore version if it is pointing to a released version. 3.1 If it is pointing to a development version bump it to the corresponding release (e.g. ">=3.8.0.dev" -> ">=3.8.0")
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
