5 ms·

Yarn made the same mistake going from 1 to 2 as Angular did. The newer version was so different. Both should have been named something else. At a certain point

Yarn made the same mistake going from 1 to 2 as Angular did. The newer version was so different. Both should have been named something else. At a certain point of incompatibility and divergence it is a different product, and the benefit you get from using a well known name is outweighed but the cost of confusion. Yarn 2 brought a lot of great improvements but since it was named "Yarn" people were expecting it to behave somewhat like the first one.

diggan 3y ago
Sometimes I wish for a SemVer iteration that does away with the major version, and requires a project to create a new library wholesale if they want to increment the major version. Every library would have minor and patch releases, but if they want to substantially change the API, they'll have to create a new library instead and ask people to move to it instead.
- svieira 3y ago
  This is similar to what Rich Hickey suggests in Spec-ulation [1] https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk
- 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 ago
    True, I take that back. Any incompatible (public API) changes warrants a new library, not just "substantial" as it's too subjective.
    - erhaetherth 3y 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.
      - diggan 3y 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.

diggan 3y ago

Sometimes I wish for a SemVer iteration that does away with the major version, and requires a project to create a new library wholesale if they want to increment the major version. Every library would have minor and patch releases, but if they want to substantially change the API, they'll have to create a new library instead and ask people to move to it instead.

svieira 3y ago
This is similar to what Rich Hickey suggests in Spec-ulation [1] https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk
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 ago
  True, I take that back. Any incompatible (public API) changes warrants a new library, not just "substantial" as it's too subjective.
  - erhaetherth 3y 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.
    - diggan 3y 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.