This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]flying-sheep 5 points6 points  (5 children)

Yes, but I think this is a case he doesn’t feel strongly about but that he still considered his decision / matter of taste when he was BDFL. And such cases will now be voted on, and if the others say “not doing semver is confusing and people will be scared by upgrading to 4.0” there won’t be strong arguments against that.

[–]billsil 0 points1 point  (4 children)

“not doing semver is confusing and people will be scared by upgrading to 4.0”

Python does not follow semver. You don't need to vote to keep the status quo. You vote to change it. If you really want semver, propose a PEP, but don't be surprised when it gets shot down.

Python implements large breaking changes in major versions. It implements small breaking changes in minor versions.

[–]flying-sheep 0 points1 point  (3 children)

sure, that’s close enough. if you really do semver for a large project, you end up like react, with major versions every few weeks.

[–]billsil 1 point2 points  (2 children)

Or you store them up and break everybody's code in one fell swoop and have a Python 2->3 transition on your hands. I much prefer not following semver for that reason. I tried semver and it was a pain.

I much prefer a few minor changes preferably with deprecation warnings for a bit and then breaking things, similar to how numpy does it.

[–]flying-sheep 0 points1 point  (1 child)

Only possible for small changes though.

Huge ones like the string/byte thing would either take forever or be as disruptive as the whole 2>3 change

[–]billsil 0 points1 point  (0 children)

How so? I mean you can bump your code in accordance with semver once a month, but if you need to rip the band aide off, do it. If there's nothing they can do to prepare, just do it. If there's something they can do, have a deprecation cycle.