4 ms·

Deprecating "legacy APIs", from the perspective of the API users, _is_ breaking core functionality. Functionality that existed previously is now gone, that is a

Deprecating "legacy APIs", from the perspective of the API users, _is_ breaking core functionality. Functionality that existed previously is now gone, that is a breaking change. Additionally, bumping a major version because a dependency changed isn't a common practice to my knowledge. In fact I'd say it's incorrect. You bump a major version if _your_ API has breaking changes. If one of your dependencies changed but you've adapted in a way that is transparent to your users, that is a patch not a major.

acemarke 2y ago
It can be more complex than that. When we shipped React-Redux v8, we rewrote our internals to drop our own subscription management logic, and switched to React's new `useSyncExternalStore` hook instead. However, `uSES` only was added with React 18, and we still wanted to support earlier versions of React that had hooks (16.8+, 17). So, we defaulted to using React's "shim" package that provided a backwards-compatible implementation of `usES`, at the cost of a bit of extra bundle size. Once React 18 reached sufficient adoption, we wanted to drop the use of the `uSES` shim package and use the built-in version, but that required React 18 as a minimum dependency. So, we did that in a major, React-Redux v9. Code _using_ React-Redux never changed in the slightest - it's still the same `useSelector` calls either way. But given that anyone attempting to mix React-Redux v9 and React <=17 would have it break, that was clearly a major version bump for us.
- swyx 2y ago
  > Deprecating "legacy APIs", from the perspective of the API users, _is_ breaking core functionality. Functionality that existed previously is now gone, that is a breaking change. gotta love hyrums law
- RadiozRadioz 2y ago
  In this case, yes, major is warranted. This type of dependency is different to what I wrote about. I was talking about dependencies of your library that are fully internal and hidden from its users, whereas this example is much wider and closer to a dependency on the environment in which your library is being used.

acemarke 2y ago

It can be more complex than that. When we shipped React-Redux v8, we rewrote our internals to drop our own subscription management logic, and switched to React's new `useSyncExternalStore` hook instead. However, `uSES` only was added with React 18, and we still wanted to support earlier versions of React that had hooks (16.8+, 17). So, we defaulted to using React's "shim" package that provided a backwards-compatible implementation of `usES`, at the cost of a bit of extra bundle size. Once React 18 reached sufficient adoption, we wanted to drop the use of the `uSES` shim package and use the built-in version, but that required React 18 as a minimum dependency. So, we did that in a major, React-Redux v9. Code _using_ React-Redux never changed in the slightest - it's still the same `useSelector` calls either way. But given that anyone attempting to mix React-Redux v9 and React <=17 would have it break, that was clearly a major version bump for us.

swyx 2y ago
> Deprecating "legacy APIs", from the perspective of the API users, _is_ breaking core functionality. Functionality that existed previously is now gone, that is a breaking change. gotta love hyrums law
RadiozRadioz 2y ago
In this case, yes, major is warranted. This type of dependency is different to what I wrote about. I was talking about dependencies of your library that are fully internal and hidden from its users, whereas this example is much wider and closer to a dependency on the environment in which your library is being used.