[chore] mark confignet as stable

[codeboten]

trafficstars

This contents of this module have not changed in over 2 years

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 90.39%. Comparing base (9553bfe) to head (770eaf1). Report is 52 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7954      +/-   ##
==========================================
+ Coverage   90.34%   90.39%   +0.04%     
==========================================
  Files         346      346              
  Lines       18194    18194              
==========================================
+ Hits        16438    16446       +8     
+ Misses       1422     1416       -6     
+ Partials      334      332       -2     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[bogdandrutu]

Can you give me until mid July before marking any config stable? I want to also discuss somewhere and document things like:

• Adding new validation rules means breaking change?
• Should we offer a "NewDefaul...." for each config and say that the behavior of the config is stable only if initialized with NewDefault?
• Adding new fields means breaking change? Let's assume someone "squash" the message into another message, then adding a field with same mapstruct value will be a breaking change, what do we do with that? What are the rules we follow.

There may be other things to document (just added some in my mind) but would like others to think of any special implications for configs that are not defined by the golang conventions of breaking compatibility,.

[bogdandrutu]

@codeboten the time in my comment was to give us time to address my concerns, so I do believe someone (who is working full time, not like me until Sept) should address them and clarify what is possible and what is not in a stable config package.

[mx-psi]

Filed #8002 to discuss the stability guarantees for configuration structures. One of these was already discussed on the VERSIONING.md document (adding new fields was deemed to be fine).

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions[bot]]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[codeboten]

Reopening this PR, with the questions answered in https://github.com/open-telemetry/opentelemetry-collector/pull/8812

[bogdandrutu]

One thing that we need to agree on, is that we should suffix everything with Config probably (instead of Settings) as discussed in one of the issues.

[bogdandrutu]

Another thing is to make sure we pass "context" everywhere. Maybe TelemetrySettings as well

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions[bot]]

Closed as inactive. Feel free to reopen if this PR is still being worked on.