Pulp_deb and supported pulpcore versions

Development
#1

The latest pulp_deb release has somehow ended up with a pulpcore version range for which there are no supported pulpcore versions:

  • pulp_deb 3.6 (latest Y-release) requires pulpcore>=3.75.0,<3.85
  • pulp_deb 3.5 requires pulpcore>=3.49.0,<3.85
  • supported pulpcore versions are ['3.28', '3.39', '3.49', '3.63', '3.73', '3.85']

I am not 100% sure exactly how we got here, but my real question is where do we go from here?

Some options:

  • Bump the pulp_deb 3.6 upper bound past the pulpcore 3.85 breaking release boundary. (Do we do this in dot releases?!)
  • Abandon the pulp_deb 3.6 branch as a supported release branch and release pulp_deb 3.7 which would use pulpcore>=3.75.0,<3.100.

Not sure if there are any other options.

2 Likes
#2

So, the way we run tests (specifically the lowerbounds scenario) it would be unwise if the lower bound (lb) of the pulpcore dependency was not a supported branch. So while technically bumping the lb would be a breaking change, we do it on release branches, whenever support for the original lb is dropped (plugin template attempts this automatically). It should be safe, because we keep supporting the pulpcore branches for products and keep them alive for their support period. Whenever no more supported pulpcore versions match the range, we can safely assume the plugin release branch does no longer need to be supported either (One less item to maintain, Yay!).

Bumping the upper bound (ub), given the code is actually tested for compatibility is not a breaking change, because you just increase the number of possible installations. This can safely happen on a release branch. If however, breaking changes need to happen to allow bumping the ub, a new y is obviously needed.

So in summary, if you can make deb 3.6 work with core 3.85 out of the box, that’s what I would suggest.

#3

Given what you said, it seems like the easiest thing to do is to release 3.7 and drop support for 3.6, because that does not require us fixing the currently broken 3.6 branch.

Again, given what you said, my intuition is that in this particular case this is also somehow the “right thing to do”. My reasoning goes as follows: If we were to fix the release 3.6 branch (by bumping its upper bound and making that work), then users upgrading to that next 3.6 Z-release could just as easily upgrade to 3.7.0. Users who don’t want to upgrade to 3.7.0 may just stay on whatever they have right now (whether that is 3.6 or 3.5, which both have the same upper bound).

Am I missing something?

1 Like
#4

Almost.
Users who never upgrade, they don’t care and so shall we not either.
Users who are on 3.6 and don’t want to change, are by definition also on a non supported pulpcore branch, so they will not receive updates anyway and fall into the first category. \o/
So if 3.7 is the easiest for you to do, go for it.

2 Likes