Cynocracy
commented
4 years ago Here's an example flow for a particularly annoying edge-case that hits us internally:
- PKG and net-istio are not versioned, which means go mod thinks they are cross-compatible always.
- Breaking PKG change is made, user is aware of it, and updates serving but not net-istio.
- Downstream consumers cannot upgrade until net-istio is fixed.
https://docs.google.com/document/d/1fkZOpl6X9JcHRsYT3VLQI2F4xVSBmwPh16XMSakfgm4/edit?usp=drive_open&ouid=109747440436841769641
Downstream consumers of Knative, and cross repo dependencies within the Knative ecosystem suffer from fewer unintentional breakages, and when breakages occur they are intentionally picked up downstream (via go get repo@v2+).
Library repositories will be constrained in the API surface changes they can make, which may impede large scale changes to, for example, PKG.
The costs depend on the estimate productivity lost by maintaining old/stale libraries.
This could be minimized by strictly adding API surface until a 'v2' is cut wherein stale and obsolete APIs are sunset. This is the approach "strongly encouraged" by go mod (read, anything else will be very painful).
This cost could be mitigated by soft-adopting semver requirements (say, by forcing PRs which make breaking API changes to have a strong justification), but that also eliminates the significant benefit of being able to leverage go mod to handle upgrades seamlessly (that is, a downstream consumer is entirely in control of when they upgrade to a new major version, major version updates are infrequent and large, but otherwise updates can occur without much intervention due to API-safe changes).
As APIDiff already exists, the timeline can be very short. The only cost is integrating within a pre-existing Knative git hook or creating a new one. I estimate between 1-3 weeks.