-
Notifications
You must be signed in to change notification settings - Fork 308
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
Twine 2.0? #490
Comments
My usual inclination is not to bundle backward incompatibilities into releases.... as it makes it even more difficulty to separate those concerns. Better would be to have lots of incompatible releases, twine 2, 3, 4 each with a separate incompatibility. Then someone can accept all (with twine 4) or only some or none based on which version they elect. However, this strategy relies on the ability to easily and rapidly make releases, which twine doesn't (yet) have #493. In any case, I'm happy to make backward incompatible releases with any number of incompatibilities as long as the users have a clear indication of how to respond to those changes. |
Honestly, only #437 has any significant user-side consequences. And well, the only actionable thing for them is to migrate away from Python 2, which is perfectly fine. In its current state, #469 gets unblocked by #437 and will not have any user-side consequences. Introducing static typing to a codebase does not require any additional end-user system requirements. Even depending on #488 is an improvement to the |
I've released 1.15 with #488. |
There's at least a few open PR's that seem like good candidates for a major release with potentially breaking changes, and it seems like there's some interest in making that release. I'm curious what other @pypa/twine-maintainers think.
Improve the check command output - Pull Request #488Also related: Prepare twine for 1.14.0 release - Pull Request #468
The text was updated successfully, but these errors were encountered: