Dropped support for 3.6 in 3.4.2?
nedbat opened this issue · comments
I thought the convention was that dropping support for a Python version was a breaking change, so this should have been 4.0.0? Maybe there are other philosophies.
BTW, I made a Twitter poll to get opinions: https://twitter.com/nedbat/status/1476539511060447235 (I'm mostly interested in figuring out what I should do for coverage.py),
I follow this logic platformdirs/platformdirs#53 (comment)
as long as you're utilizing
python_requiresit shouldn't break old versions (they'll still be able to successfully install and use unbounded) -- so I use a minor bump
Next time you drop a python version, please bump the minor version at least. Patch version is expected to only receive bugfixes and dropping a python version is clearly not a bug fix. Most package maintainers do know to ceil versions correctly and by not doing this you will encourage them to lock dependencies to prevent breaking their CI, which is causing a cascaded breakage for consumers as sooner or later they will endup with conflicts.
Let's agree to disagree on the topic. As the Twitter poll above says seems the community is split if dropping a python version is patch or major. Roughly half go each way, so let's conclude we're in opposing branches. I consider the release correct.
The poll was split between major and minor. @ssbarnea is asking that you not do a patch version bump.
Please reread the tweet, there's no mention of minor in that poll, and the example implies patch, not minor (otherwise you would have said 6.5.0 vs 7.0.0 and not 6.4.2 vs 7.0.0).
I personally consider that dropping a Python version adds no real change. Breaking changes/removeals are major version changes, feature additions are minor version changes. All other changes, e.g. misc and bug fixes are patch ones. Unless you're using an ancient pip (pre 9.0 or so) there's no way dropping a Python version will break you.
Using twitter for surveys will always give very biased results but even in this case it is not hard to see that most people want a major (signifiant) version bump when something is removed. If the same question would have being posted to https://discuss.python.org/c/packaging/ it would have being a little given even more clear results.
In my case I use latest pip versions and I was still affected a little bit because we use pip-tools to compile lock files for testing dependencies. That produced an updated lock file which failed to run py36 because that version was no longer supported (the lock file is generated with another python version). I know you could say that different lock files would have being better but they do come with other problems.
To say it again, do not remove features in patch versions, is simple as this: py36 was a feature. I am bit related regarding minor vs major bumping but when it comes to patch, it is clearly bad thing to do.
I am not asking for a yanking but I wanted to clarify that and prevent it from happening in the future, as its a bad practice.
TBH, that is the first case where I see a mature package dropping a feature in a patch version. The way I see it, is that doing this is breaking the law of surprise... and we know what happens when the universe order is broken ;)
To be honest this is a really good motivation to switch to calver and avoid such polemics over the different interpretations of semantic versioning.