So how does it work if a library owner changes something in his library—do they have to update all projects that depend on it and then push this as a single commit?
Generally it's on the library owner to update all projects that depend on it, i.e. not break their tests, but this need not be done as a single commit. More concretely:
If the change is internal to the library, i.e. does not require the projects that depend on it to change the code, then the library owner simply tests that none of the affected tests break (globally), and updates their library.
If the change requires dependent projects to change their code, then some way is first figured out of having code that would work with both versions of the library, then updating all the callers individually (e.g. in a separate mostly-automated change for each project to review), then we're in the first situation above.
“Old APIs can be removed with confidence, because it can be proven that all callers have been migrated to new APIs.” (from the older article)
Yes. And that is easy because the tooling can find all callers and the test infrastructure can find and run all related tests (even, if need be, literally every test).
svat|7 years ago
If the change is internal to the library, i.e. does not require the projects that depend on it to change the code, then the library owner simply tests that none of the affected tests break (globally), and updates their library.
If the change requires dependent projects to change their code, then some way is first figured out of having code that would work with both versions of the library, then updating all the callers individually (e.g. in a separate mostly-automated change for each project to review), then we're in the first situation above.
“Old APIs can be removed with confidence, because it can be proven that all callers have been migrated to new APIs.” (from the older article)
shereadsthenews|7 years ago