Should dependency bumps trigger a minor version bump for a stubs package?

[AlexWaygood]

In https://github.com/python/typeshed/issues/10825, it's been suggested that the change to require urllib3>=2 in our types-requests stubs probably should have been accompanied by (at least) a minor version bump in types-requests.

I'm somewhat sympathetic to that argument, but I'm not really an expert on the versioning scheme we use. Perhaps we could establish a general rule where is the stub-uploader detects a change in the dependencies of the stub, that triggers a minor version bump rather than a micro version bump. What do we think — would this be a change worth making? Would it be compatible with our versioning scheme?

[AlexWaygood]

(Note: I think it would be incorrect for users to rely on typeshed never making breaking changes in a micro version bump. We should probably also improve our docs over at typeshed to make it clearer that people need to pin their stubs packages precisely if they want to avoid unexpected breaking changes. That doesn't necessarily mean that this change wouldn't be worth making, though, just that there are other things we should also do.)

[hauntsaninja]

Our versions primarily match upstream versions. I think this is important for users and general sanity, so I don't think we should make any changes in stub_uploader.

I agree the situation is slightly unfortunate. urllib3 is very widely used and very widely pinned. But dependency resolvers should be able to figure it out, users can always pin, changes to deps ranges aren't really breaking changes. It would have been minorly nice if we'd waited to coincide it with a bump in upstream requests version (we've done this in the past with a much more breaking protobuf change), but I think is basically fine as it happened.

(A separate thing that issue brings up is that PEP 561 precedence is not very good for cases where types get upstreamed)

[srittau]

We could maybe add a note about our versioning scheme to package descriptions.

Another possibility is to use the epoch for signalling breaking changes, but I don't really want to use it if it can be avoided.

[srittau]

(Also we should probably move this discussion to typeshed for more visibility.)

[AlexWaygood]

(Also we should probably move this discussion to typeshed for more visibility.)

Sure — I opened it here as I figured it would require changes to the code in this repo rather than any code changes in typeshed, but happy to have it in either location :-)

Do you have the power to transfer it over to the typeshed tracker? I don't :/

[srittau]

Seems we can only move issues between the same user or org. But I'll ping @JelleZijlstra, @Akuli and @sobolevn as the other active typeshed maintainers.

[ilevkivskyi]

IIRC the current scheme is quite intentional. There were long discussions couple years ago, and after all we agreed on this simple logic. Otherwise it will be hard to reason about which version of stubs correspond to which runtime version. At that time however we didn't think that runtime packages will ever be dependencies of stub packages. FWIW I would propose to keep everything as is.

[srittau]

Closing in favor of python/typeshed#10837, since I think we decided here that we can't change the basic way our versions work.