4 ms·
It's very common to have breaking changes that you need to carefully manage in a company's internal code, and where managing that as a full-on deprecation isn't
by bbrazil 11y ago
It's very common to have breaking changes that you need to carefully manage in a company's internal code, and where managing that as a full-on deprecation isn't worth the effort. Moving faster is often the better choice compared to never refactoring and improving the codebase.
- chei0aiV 11y agoI think I would prefer to base on proven libraries with stable interfaces. Do you have any examples of these breakages?
- bbrazil 11y agoI'm talking about internal libraries of a company, where there is no proven library with a stable interface as it's continuously evolving - similar to a young library in the OSS world that has no reasonable substitute. It might be something like a new parameter to a function, or an additional method call you need to make in a given version.
- chei0aiV 11y agoOh. Obviously for internal libraries you should do whatever you like, including bundling. I thought you were talking about open source libraries.