Last question that keeps popping up is a request for some kind of minimum required deprecation period before removal can take place. I’m reluctant to pick a number out of the air.
Perhaps a better approach would be to decide how long we are willing to fully support a v1.0 branch of OpenTelemetry before even considering something like a v2.0. But, again, there should be some kind of rationale to the number we pick, and I currently do not have one.
In general, I would prefer that we get creative about adding new functionality and better interfaces in v1.0, rather than contemplate a v2.0 at this time. But we do have to say something about a timeframe, or the question will continue to come up.
@tedsuo I am a strong proponent of allowing the sdk and api versions to diverge. As far as putting the API in a separate repo, I don't think that's required but I am also not strongly against.
One is the location of “core plugins” like OTLP, jaeger, prom, etc. It seems to me that everything except for OTLP and trace-context would be better served by living in contrib, and getting bundled in as a distro, rather than living in core as part of the SDK.
Anything the spec says we MUST have, I think should be in the core repo. Good example is the jaeger propagator. In order to satisfy the environment variable configuration spec, the sdk must depend on it. If it lives in contrib, then you have a case where the core repo depends on a module in contrib which seems backwards to me.
But we do have to say something about a timeframe, or the question will continue to come up.
I think if we say something along the lines of "All major versions will be supported for at least 3 years from initial (x.0.0) release, and at least 1 year from the latest minor (x.y.0) release" then we are being clear that it will be supported, while also not closing the door on the idea of a 2.0 in that timeframe. If we want to release a 2.0 while 1.0 is still in the promised support period, we simply have to maintain both. This serves the (i believe positive) purpose of dissuading us from trying to get trigger-happy with major version releases.
Right. I think the question is, would it be feasible to give write access of portions of core to additional maintainers, so they can focus on things like prometheus support, without needing to give them full write access to the entire repo. Or would that just be stressful and difficult for the primary language maintainers.
To be clear, I’m just spitballing ideas right now, so let me back up a bit.
I get a sense that maintainers are having to write a lot of code right now, which leaves less time for code review, which makes it harder to parallelize. I’d like to understand how maintainers are feeling about their workload, and focus on improvements to our org structure in the new year.
If I could materialize more people by snapping my fingers, what type of people would y’all want? And what would make it difficult to manage additional help?
I wanted to get the opinions of the other maintainers on how to handle errors in the API or in the setup process. Currently in JS the logger is an SDK-only concept, so we typically do all of our error handling in the SDK or in some API cases we do the no-op behavior. But when we do have errors in the API, how do we want to handle them? Seems we have 3 options:
Throwing obviously runs the risk of crashing the program, but if there is an error in the setup code this may be the correct behavior. Logging to console can also break end-user applications in less obvious ways. If a program reads the output of another program and we change that output, we can break the application which is reading the output. Creating an API-level global logger seems like the correct choice to me, but there is no spec for logging in the API