You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Consider Evaluating Experimental Types as Part of Back Compat Handling #12132
Our back compat handling currently doesn't inspect any experimental attributes on types. We should consider ignoring / skipping back compat application for types that are labeled as experimental between releases.
🎯 Issue Triage
This requests that C# client-emitter compatibility processing recognize experimental types and avoid preserving their prior contracts across releases. Category: Feature Request Area: emitter:client:csharp
🔍 Analysis
The affected component is the C# client emitter's ApiCompatVersion/last-contract handling. The compatibility pass currently applies preserved API details without consulting experimental metadata, so intentionally unstable types may receive compatibility transformations that conflict with their current shape. #12133 is related: it reports obsolete enum serialization being preserved after an experimental type changes to an extensible enum, but it is a concrete bug rather than a duplicate of this broader policy request.
📝 Suggested next steps
Define whether experimental status in either the baseline, current contract, or both should suppress compatibility handling.
Add compatibility tests covering types entering, leaving, and remaining experimental between releases.
Verify that suppression applies consistently to models, enums/unions, properties, and generated serialization.
Activity
github-actions commentedon Oct 7, 2026
🎯 Issue Triage
This requests that C# client-emitter compatibility processing recognize experimental types and avoid preserving their prior contracts across releases.
Category: Feature Request
Area:
emitter:client:csharp🔍 Analysis
The affected component is the C# client emitter's
ApiCompatVersion/last-contract handling. The compatibility pass currently applies preserved API details without consulting experimental metadata, so intentionally unstable types may receive compatibility transformations that conflict with their current shape. #12133 is related: it reports obsolete enum serialization being preserved after an experimental type changes to an extensible enum, but it is a concrete bug rather than a duplicate of this broader policy request.📝 Suggested next steps
Skip C# back compatibility for previously released experimental types (…