Proposal for having a single feature band going forward - #373
Proposal for having a single feature band going forward #373marcpopMSFT wants to merge 1 commit into
Conversation
…l configuration that all tools rely on to get new feature work.
|
|
||
| **Owner** [marcpopMSFT](https://github.com/marcpopMSFT) | ||
|
|
||
| Today, SDK feature bands, SDK tools, and Visual Studio are coupled in ways that is complex to manage and confusing for users. The challenge with changing this is users can receive new features or behavior changes without intentionally opting in. This is especially problematic for managed environments and source build partners that prioritize stability. We propose a single SDK feature band strategy, combined with a global feature channel setting that all SDK-loaded components honor. This setting has three states: baseline, stable, and preview. New behavior is always disabled in baseline, and initially enabled only in preview. |
There was a problem hiding this comment.
Stable isn't explained in the same way that baseline and preview was.
| - Behavior aligns with VS stable expectations. | ||
| - Mid-cycle surprises are reduced. | ||
|
|
||
| ### Scenario 3: Canary/Insider users validate upcoming behavior |
There was a problem hiding this comment.
| ### Scenario 3: Canary/Insider users validate upcoming behavior | |
| ### Scenario 3: Visual Studio Canary/Insider users validate upcoming behavior |
This seems like it's just for VS
|
|
||
| Today, SDK feature bands, SDK tools, and Visual Studio are coupled in ways that is complex to manage and confusing for users. The challenge with changing this is users can receive new features or behavior changes without intentionally opting in. This is especially problematic for managed environments and source build partners that prioritize stability. We propose a single SDK feature band strategy, combined with a global feature channel setting that all SDK-loaded components honor. This setting has three states: baseline, stable, and preview. New behavior is always disabled in baseline, and initially enabled only in preview. | ||
|
|
||
| ## Scenarios and User Experience |
There was a problem hiding this comment.
I'd like to see scenarios described for stable, baseline and preview for SDK users not using VS. Including if there's a difference for the different acquisition methods.
| - A feature starts as preview-on, stable-off, baseline-off. | ||
| - Promotion to stable requires explicit approval and release notes in a planned update. | ||
| - Baseline remains off by default, with opt-in available for customers that explicitly choose it. | ||
| - Minimum preview soak time before promotion is two months. |
There was a problem hiding this comment.
Two months seems a bit long for low-risk changes. UPDATE: I see this was mentioned as well in the Risks and Unknown section
| 3. Host-computed default written by SDK startup | ||
| 4. SDK build-time default | ||
|
|
||
| Global.json integration may be added later, but is not required for the initial design. |
There was a problem hiding this comment.
| Global.json integration may be added later, but is not required for the initial design. | |
| global.json integration may be added later, but is not required for the initial design. |
I understand why you maybe don't want to add this initially but this was the method I was hoping to use so I could share the config with the other developers and know that CI will use the same config.
| - Internal branch build: | ||
| - Stable branding | ||
| - Includes MSRC fixes and latest runtimes | ||
| - Insert into VS stable and oobstable |
There was a problem hiding this comment.
| - Insert into VS stable and oobstable | |
| - Insert into VS stable and unstable |
Maybe a typo or an actual internal name :P
|
|
||
| Unknowns to validate during review: | ||
|
|
||
| - Whether `baseline` is intuitive enough for external customers and partners. |
There was a problem hiding this comment.
Baseline is the most stable so I guess there could be some confusion, but I worry that some will misunderstand the guarantees given by baseline and stable and unnecessarily choose(mandate) baseline (irrespective of the name but naming helps alot with conveying intent). So by itself baseline is understandable but also having a channel named stable makes it maybe less obvious.
|
|
||
| No. Component-level flags can remain. This proposal adds a single, global compatibility channel that defines default behavior posture. | ||
|
|
||
| ### Open questions to resolve |
There was a problem hiding this comment.
Should a change to N.0.1xx be up for consideration with this change, maybe it should now align with the runtime version? Support for the SDK and the different feature bands have been misunderstood sometimes and especially related to the runtime as that ships with the SDK but ia installed seperately where you deploy.
|
@zivkan as we've touched on feature roll out/behavior changes for some of our discussions. |
|
|
||
| **Owner** [marcpopMSFT](https://github.com/marcpopMSFT) | ||
|
|
||
| Today, SDK feature bands, SDK tools, and Visual Studio are coupled in ways that is complex to manage and confusing for users. The challenge with changing this is users can receive new features or behavior changes without intentionally opting in. This is especially problematic for managed environments and source build partners that prioritize stability. We propose a single SDK feature band strategy, combined with a global feature channel setting that all SDK-loaded components honor. This setting has three states: baseline, stable, and preview. New behavior is always disabled in baseline, and initially enabled only in preview. |
There was a problem hiding this comment.
I don't quite follow how introducing a new concept (channel setting) makes it less complex.
I'd be good to explain why staying on older SDK version that only receives security fixes isn't simpler and sufficient for customers who need stability. Is it because VS is tied to the latest SDK?
3 participants
with a central configuration that all tools rely on to get new feature work.