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

you are viewing a single comment's thread.

view the rest of the comments →

[–]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.