-
Notifications
You must be signed in to change notification settings - Fork 344
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
Add license and classifiers metadata #1213
Conversation
Co-authored-by: Matt Martz <matt@sivel.net>
* Add license and classifiers metadata * Correct license value. Co-authored-by: Matt Martz <matt@sivel.net> (cherry picked from commit d1417e5)
* Add license and classifiers metadata * Correct license value. Co-authored-by: Matt Martz <matt@sivel.net> (cherry picked from commit d1417e5)
@Shrews shall we also backport this for 2.0 and 2.1? Therefore we could release a new version to pypi with yank the incompatible legacy versions? |
@hswong3i The 2.1 and earlier releases will receive only security fixes. Those branches will not receive this change. |
Yes as a human being we all respecting the community policy for just patching for security for 2.0/2.1 release, but as a platform and tool as pypi.org and pip couldn't understand this. If we only hotfix 2.2/2.3 release, pypi.org and pip will still report 2.1.x as suitable and available version for installation, which not sync with what we claimed in document for human... Shall we give an exception for solving a technical issue by technical but not by documentation only? |
P.S. as a rpm/deb packager with OBS, I had already EXCLUDE all 2.x build for legacy OS with Python 3.6 but just provide 1.4.9. So basically I am respecting community policy and already solve the problem for my own daily use case under my own controlled environment. But this didn't solve the unexpected behavior if people follow our document and install with pip directly. We could patch the document with sorry, but patch the code could solve the root cause... |
Fixes #1196