3 ms·
The problem with semver is what constitutes "substantially"; because it's been left to subjective interpretation, we end up with these weird situations. What ma
by politelemon 3y ago
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.
- diggan 3y agoTrue, I take that back. Any incompatible (public API) changes warrants a new library, not just "substantial" as it's too subjective.
- erhaetherth 3y agoNo, 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.
- diggan 3y agoExcept 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.