4 ms·
>People change something in their module. They don't test any upstream modules because it's not their problem anymore. If you use any sort of versioning this s
by runT1ME 12y ago
>People change something in their module. They don't test any upstream modules because it's not their problem anymore.
If you use any sort of versioning this shouldn't ever cause a problem.
- Touche 12y agoYeah, 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 12y 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 12y agoOr you bump an API version. And the fixes are gradual everywhere.
- Touche 12y agoThe parent was advocating not versioning.
- lbrandy 12y agoI had a problem so I decided to use versioning, now I have a combinatorially exploding number of problems.