-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: Move API code to a separate module/repo #1649
Comments
For packages that are already v1, i'm not sure there value other than maybe having fewer dependencies. For otel, we mostly have lots of modules because:
Looking at A library with Prom instrumentation is probably going to use There might be value in splitting out the http Prometheus client. OTel-go uses go.opentelemetry.io/build-tools/multimod to manage versions. |
Thanks!
The thing is -- it's only because we forced it so, we vendor some stuff and made some trade-offs to reduce num of deps. I wished we could add some simple deps (e.g. for MacOS process things). On the other hand, everyone uses process collector, so they will need to consume this anyway... and would enjoy less deps 🙃 Generally another aspect why it's useful to split those - is to version them differently. So e.g. creating v2 or v10 of collectors, testutils or http API is bit more manageable for users, doing same for core module is painful (arguably too big adoption/module to bump major version every year with little change e.g. see what happens with yaml v3 🙈 ) and there is smaller pressure. For example doing #1639 in some Are we too cautious with v2? (it has this path rename issue users might be not aware of Nevertheless I agree we should avoid small multi-module as much as possible. We can consider doing this for HTTP API one day, but only when we have a clear idea what the next thing looks like. |
Yeah, you can definitely split and do a v2 of just a single folder if you need to. I would wait until you are ready to release the v2 of that folder to make the new module. But if you are planning to do a v2, you could also make other small changes (e.g. your fancy NewDesc versioning :)) while you are at it. |
Changed the title to focus on API move only. We could use that for mentorship project. |
Proposal
To reduce the damage radius of release (e.g. compatibility issues), increase dev velocity and reduce indirect/direct dependencies for downstream users, we could consider splitting client_golang into multiple modules.
Specifically I would move to new modules:
We could split more, but other stuff tended to be less problematic in past and moving slower, or not have new deps.
Risks
Personally, the main pain-point of using multi-module SDKs (e.g. otel-go) were:
Would be curious of @dashpole opinion if he would advise this (:
The text was updated successfully, but these errors were encountered: