-
Notifications
You must be signed in to change notification settings - Fork 35
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
Declare stability per capability or for all spec? #146
Comments
I think that makes sense. BindPlane does use Packages and PackageStatuses for agent upgrade and it was worked well. It does not currently use ConnectionSettings. |
@andykellr are there any other capabilities that BindPlane does not use? Do you utilize everything except Connection Settings? |
ConnectionSettings and AgentIdentification are not currently used by BindPlane. |
Discussed in workgroup meeting today and decided that it is reasonable to declare only portions of the spec stable and keep less-tested parts as beta. I will work on figuring out the exact labeling mechanism. |
Contribures open-telemetry#146 As agreed we will mark certain capabilities as Beta for now, until we have more confidence that they are well-specified. This will be primarily driven by feedback from implementations.
Contribures open-telemetry#146 As agreed we will mark certain capabilities as Beta for now, until we have more confidence that they are well-specified. This will be primarily driven by feedback from implementations. Capabilities marked Beta: - Packages - Connection Settings Managements - Own Telemetry Reporting
Contributes to open-telemetry#146 As agreed we will mark certain capabilities as Beta for now, until we have more confidence that they are well-specified. This will be primarily driven by feedback from implementations. Capabilities marked Beta: - Packages - Connection Settings Managements - Own Telemetry Reporting
Contributes to open-telemetry#146 As agreed we will mark certain capabilities as Beta for now, until we have more confidence that they are well-specified. This will be primarily driven by feedback from implementations. Capabilities marked Beta: - Packages - Connection Settings Managements - Own Telemetry Reporting
Contributes to open-telemetry#146 As agreed we will mark certain capabilities as Beta for now, until we have more confidence that they are well-specified. This will be primarily driven by feedback from implementations. Capabilities marked Beta: - Packages - Connection Settings Managements - Own Telemetry Reporting - Server to Agent Command.
Contributes to #146 As agreed we will mark certain capabilities as Beta for now, until we have more confidence that they are well-specified. This will be primarily driven by feedback from implementations. Capabilities marked Beta: - Packages - Connection Settings Managements - Own Telemetry Reporting - Server to Agent Command.
Done in #147 |
We discussed that we want to wait for some OpAMP implementations to complete before we declare the spec stable, so that there is time to learn from the implementations and adjust the spec if needed. However the implementations that are in progress don't utilize all OpAMP capabilities, so we can't expect to learn much about these areas.
Should we declare stability of the spec for the capabilities that we know are relatively well-tested and move the other capabilities to a separate section and mark as "Beta" addition to the spec for now?
The spec sections and capabilities I am less confident about and which I think are not used in any implementations so far are:
We can probably mark these sections as
[Beta]
and the rest of the sections can be declaredStable
.@open-telemetry/opamp-spec-approvers what do you think?
The text was updated successfully, but these errors were encountered: