According to https://packaging.python.org/guides/dropping-older-python-versions/#dropping-a-python-release and adding such field on other project, I think we need a 3.17.4 release with the python_requires that includes Python 2 and then a release 3.18.1 that drops Python 2 support.

@Lothiraldan As the document you linked above, and the semver said, I think publish a major version (4.0.0) and yank the current version 3.18.0 is the right way.

@acozzette @TeBoring @haberman Please take a look.

@aisk Sorry to ask, but where is the 4.0.0 version? I don't see it on Pypi nor see a tag or branch for 4.0.0.

From past releases of protobuf ,it looks like the version numbers need to match the version of the runtime and protoc.

I think what @Lothiraldan suggested should work well:

According to https://packaging.python.org/guides/dropping-older-python-versions/#dropping-a-python-release and adding such field on other project, I think we need a 3.17.4 release with the python_requires that includes Python 2 and then a release 3.18.1 that drops Python 2 support.

This change will break old codes so it's better to have a major release. But if protobuf have it's own versioning strategy I think it's ok, the python_requires field should solve most problem (except people who have old version pip / setuptools).

I think we need a 3.17.4 release with the python_requires that includes Python 2 and then a release 3.18.1 that drops Python 2 support.

They should probably just release 3.18.1 and yank or delete 3.18.0 from PyPI

Thanks, @aisk. I am getting ready to do a 3.18.1 release that will include this fix.