[chore] Explicitly note that service and otelcol are not part of 1.0

[mx-psi]

Description

Explicitly excludes service and otelcol from 1.0 efforts.

These modules are useful for distribution maintainers but not end-users, for which the 1.0 effort is targeted.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.33%. Comparing base (43ed618) to head (11d85e4).
Report is 13 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10643      +/-   ##
==========================================
+ Coverage   92.32%   92.33%   +0.01%     
==========================================
  Files         397      403       +6     
  Lines       18701    18733      +32     
==========================================
+ Hits        17265    17297      +32     
  Misses       1076     1076              
  Partials      360      360              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mx-psi]

#9375 and the Collector v1 board would need an update if we merge this

[mx-psi]

To add more context to this: the Collector 1.0 effort is focused on providing stability to end users. On the 2024-07-17 Collector Stability WG meeting we discussed the following that feels (to me at least) as a compelling argument for removing this from Collector 1.0 efforts:

• A Go module marked as 1.0 has two kinds of stability: symbol/Go API stability (not changing/removing public symbols that are part of the public API), and behavior stability. End-users of the binary care only about behavior stability.
• There is a link between Go API stability and Go module versioning in that the components of the Collector such as the OTLP receiver are published as a Go module and their Go module version matches their component version. Therefore we need to mark OTLP receiver and friends as 1.0 and provide both kinds of stability for these modules. Because of our VERSIONING.md requirements, we also need to mark their dependencies as 1.0.
• service and otelcol are not a dependency of any component. Therefore we don't necessarily need to provide Go API stability for these in order to call a Collector distribution 1.0. End users only care about behavior stability from these, which we can provide.

A question was raised about this in how do we ensure users understand the difference. The main goal and wording we can use for Collector 1.0 stability is to say that we guarantee behavior stability of the binary, but not Go API stability. This is what other projects such as Kubernetes have successfully communicated (k8s.io Go modules are 0.x but the binary is 1.x).

[songy23]

These modules are useful for distribution maintainers but not end-users, for which the 1.0 effort is targeted.

Agree with otelcol, but for service shouldn't the configs at least be stable for end users?

[mx-psi]

These modules are useful for distribution maintainers but not end-users, for which the 1.0 effort is targeted.

Agree with otelcol, but for service shouldn't the configs at least be stable for end users?

I reworded to clarify that we will guarantee behavior stability

[songy23]

LGTM

[atoulme]

What is a good estimate of the work to get service and otelcol stable? If we don't do this for the Collector 1.0, when will it be done? What expectations should we set and should we care?

I want to understand the range of options we can consider here.

• What is the expectation of API to be offered by those modules, given that they participate in the binary behavior?
• Can we move most of the API of those modules to an internal module and expose virtually no API for this release?

[mx-psi]

What is a good estimate of the work to get service and otelcol stable?

I think the main problem is that we don't have an estimate, because this part of the API has much fewer users than the others and as such we have not really built a backlog of issues to consider here.

If we don't do this for the Collector 1.0, when will it be done?

I expect we will continue to work on stabilizing other modules after 1.0, but I don't think this would fall in the scope of the GA roadmap. As with anything in open source, it's hard to tell 😄

What expectations should we set and should we care?

I don't understand this, you mean what expectations should we set regarding when otelcol and service will reach 1.0?

What is the expectation of API to be offered by those modules, given that they participate in the binary behavior?

The functionality provided at the point where we announce Collector 1.0 will continue to be supported with the same behavior until a 2.0 Collector release is done (modulo fixing bugs, which needs a judgement call)

Can we move most of the API of those modules to an internal module and expose virtually no API for this release?

It's hard to tell, but I think probably the answer is 'no' or at least 'not for most of it'. We have a bunch of users (vendor-backed distros, Jaeger, Agents that include OTel related functionality) of these APIs

[codeboten]

I'm ok with not stabilizing the go apis for those modules as part of what we'll call 1.0. Will need to review the worked tagged with those modules to ensure that we only move issues that cover the API out of the scope of 1.0

[mx-psi]

cc @open-telemetry/collector-approvers I will merge this on Wednesday EU morning unless anybody blocks by then

[atoulme]

Thanks for answering my questions. I am ok with this approach, let’s deliver everything early and come back and deliver this next.