undefined | Better HN

0 pointspolitelemon2y ago0 comments

The problem with semver is what constitutes "substantially"; because it's been left to subjective interpretation, we end up with these weird situations. What may invoke a feeling of "This should have been a new library" is different for each team. Even a minor change with a deprecated method can invoke such a reaction depending on how a team has been using that library.

0 comments

3 comments · 1 top-level

diggan2y ago· 2 in thread

True, I take that back. Any incompatible (public API) changes warrants a new library, not just "substantial" as it's too subjective.

erhaetherth2y ago

No, c'mon, that's taking it too far. React, for example, has been doing a wonderful job. They deprecate during one major version, and then maybe they'll remove in the next major version after that. Usually stuff just keeps working. Maybe you have to add an `UNSTABLE_` prefix or something here and there to maintain backwards-compat, but all the breakages have been very minimal and they give you like a year for you to clean up your usages of any deprecated functions so that that your next upgrade is seamless.

diggan2y ago

Except that forces people to always try to stay bleeding edge, otherwise upgrading in the future becomes a huge hassle.

Compare this with Clojure where you can almost guarantee that you can move between any stable version without having to change your code, even if you jump 4-5 versions.

j / k navigate · click thread line to collapse