4 ms·
Yeah, doing it this way they can never make API incompatible changes without also fixing everything downstream... which effectively means once a library is popu
by Touche 13y ago
Yeah, doing it this way they can never make API incompatible changes without also fixing everything downstream... which effectively means once a library is popular enough it is locked at it's current API forever.
- cben 13y agoI've seen that happen at Google. At some point it's easier to write a new (differently named) library. Monolithic codebase + renames = poor man's versioning. BUT this allows you to pay the prices of versioning (downstream burdened with rewriting => they never do => old code lives indefinitely) only in the worst cases. If done right (lots of tests, great CI infrastructure), fixing everything downstream is practical in many cases, and can be a win. A subtler question is how this interplays with branching. You can't be expected to update downstream on every random/abandoned branch out there, only the head. Which deters people from branching because then it's their responsibility to keep up...
- Peaker 13y agoOr you bump an API version. And the fixes are gradual everywhere.
- Touche 13y agoThe parent was advocating not versioning.