SDK 2.0 Planning

[dyladan]

This issue is to discuss the concrete mechanics for proposal 1 described in #4083.

In this scenario, we will stop new feature development on the 1.x lines of our stable signals: traces, metrics, baggage, and context. This will allow us to focus our effort on the 2.0 line with the goal of completing the work faster than if we had continued feature development on the 1.x line. High priority bug fixes will continue to be implemented in the 1.x line. Any pull request author adding a new feature to the 1.x line will be expected to first add it to the 2.x line, but most feature development should target the 2.x line.

• SDK 2.0 Branch Structure #4125
• SDK 2.0 Documentation Plan #4126
• SDK 2.0 Plan for unstable packages #4127
• SDK 2.0 OTLP exporters #4128

Timeline

Planning

This phase is expected to take about a month. Target for completion is the last SIG meeting in September. During this phase we are filing issues for breaking changes we would like to make, prioritizing those issues, and accepting or rejecting them for the project.

Pre-Alpha Development

During this phase, there is no guarantee of stability. It is possible that at times the tests may fail or the project may even fail to compile entirely. It is not suitable for any use other than development. There may or may not be any releases.

Alpha Release

During this phase, there is no guarantee of interface stability. Any release may break compatibility with the previous version. There will likely be releases, although they may not be on a regular cadence. Code is not considered production ready.

Beta Release

During this phase, there should be a reasonable level of interface stability. Breaking changes will be considered, but may be rejected if the value doesn't warrant the user pain of a breaking change. Releases will happen regularly. Forward looking projects may decide to use these releases in production.

Unstable Packages Target 2.x

During the beta phase, the unstable packages will be updated to target the 2.x line. Future releases of the unstable packages will not work with 1.x SDK packages.

Release Candidate

During this phase, interfaces should be stable. Forward looking projects may decide to use these releases in production and other organizations may be testing and validating them internally.

Stable Release

Release of the 2.0 SDK packages. 1.x is considered to be legacy and only security and priority bug fixes are applied for the next 6 months.

[t2t2]

In regards to branching, I think it would be better to keep 1.x versions in main and develop in 2.x/next/... branch (until stable release when they can be pushed into main, be it merging or branch renames)

The main reason would be documentation/readme and the google search factor - most links and search results would point towards the main branch with the expectation that it's most up to date for the version expected to be actually used, which the 2.x won't be for a while as noted by the timeline

Any sort of header in the readme has the issue that people don't read (aka banner blindness), most people would either scroll past / ctrl+f for what they seek without knowing they're seeing information that may not apply to them at all (in case of breaking change)

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.