Earlier quoted context omitted.
This is what semantic versioning is for, though. Breaking changes to the API that still serve the same function in an app would not unreasonably be a new major version of the same package. No one is obligated to upgrade to the latest major version. A complete rewrite would be a ship of theseus situation. It's all new code, and the API may be different, but it still exists to serve the same purpose in an app. Why pret…
Yeah but think of it from an (Linux OS) maintainer perspective: if you don't have a supported way to install parallel versions of the same package, you're stuck creating it under a new name (e.g., request999) because packages won't update. This is the solution in, e.g., Fedora where "junit" means junit4 and "junit5" is a separate package. Over time, junit might become deprecated and be removed from Fedora when all de…
I'm a library maintainer, and it doesn't make any sense to me to create totally different packages with different names just to handle a breaking change. This is what semantic versioning exists for.