-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Follow semantic versioning in mypy version pins #96
Comments
I agree. Let's try that. I'll update the pin and make a release. |
I realize I didn't state it explicitly, but it probably still makes sense to pin the minimum version too, so people get at least the mypy version the release was tested with, but possibly a newer patch version, when available, i.e. for a release that was tested against 1.0.0 the requirement would be |
Yeah, that's exactly what I'm planning to do. |
mypy-zope-0.9.1 is released! |
I think until mypy reached 1.0.0 it was a fine policy to pin to the mypy version that was released at the time, since the plugin system is not guaranteed to be stable and the version numbering was sort of semantic, but not really, since it used number digits rather, than numbers separated by dots.
But now that mypy is following semantic versioning rules I think you should consider only pinning the mypy version to before the next minor version, so if the current version was 1.0.0, you would pin to <1.1.0, rather than ==1.0.0, so patch releases, like 1.0.1, which will often contain important bug fixes can still be installed without having to force ignore the version pin.
The text was updated successfully, but these errors were encountered: