[marcpopMSFT]

Aligning the SDK with the current tooling and VS release schedule and removing the confusion of feature bands while simplifying our infrastructure.

[Frulfump]

@zivkan as we've touched on feature roll out/behavior changes for some of our discussions.

[jkotas]

cc @dotnet/distro-maintainers

[joeloff]

@marcpopMSFT Can you add a scenario for Microsoft Update? Currently feature bands are serviced separately. Someone on 1xx will only be offer 1xx updates. But if they are on 2xx or 4xx, they'll get those too. SDKs from VS are serviced as from VS. The standalone SDK includes all the runtimes so those fixes are rolled up and a single offering can target multiple products.

[marcpopMSFT]

@marcpopMSFT Can you add a scenario for Microsoft Update? Currently feature bands are serviced separately. Someone on 1xx will only be offer 1xx updates. But if they are on 2xx or 4xx, they'll get those too. SDKs from VS are serviced as from VS. The standalone SDK includes all the runtimes so those fixes are rolled up and a single offering can target multiple products.

@joeloff can you provide more info on what you're looking for? Us collapsing into a single band means we'd only offer MU for that one band.

[mmitche]

Worth calling out that source build validation will probably stay about the same, but to be more explicit, we're saying that N(flag=baseline) must be able to build N+1. We should make it an explicit goal to avoid taking dependencies on preview or stable features to be able to build N+1.

I don't necessarily think it's a hard requirement, but it's probably good guidnace.

[mthalman]

Worth calling out that source build validation will probably stay about the same, but to be more explicit, we're saying that N(flag=baseline) must be able to build N+1. We should make it an explicit goal to avoid taking dependencies on preview or stable features to be able to build N+1.

I don't necessarily think it's a hard requirement, but it's probably good guidnace.

Eesh, that's a really good point. And actually that's a regression from how it currently works in 10.0. In 10.0.4xx, you can depend on features that came from 10.0.3xx, for example. Relevant doc links:

• https://github.com/dotnet/source-build/blob/main/Documentation/feature-band-source-building.md#3xx4xx-band-initial-release-n0b00
• https://github.com/dotnet/source-build/blob/main/Documentation/feature-band-source-building.md#3xx4xx-band-servicing-n0b01

So saying you can only depend on baseline channel definitely limits things.

[marcpopMSFT]

Worth calling out that source build validation will probably stay about the same, but to be more explicit, we're saying that N(flag=baseline) must be able to build N+1. We should make it an explicit goal to avoid taking dependencies on preview or stable features to be able to build N+1.
I don't necessarily think it's a hard requirement, but it's probably good guidnace.

Eesh, that's a really good point. And actually that's a regression from how it currently works in 10.0. In 10.0.4xx, you can depend on features that came from 10.0.3xx, for example. Relevant doc links:

• https://github.com/dotnet/source-build/blob/main/Documentation/feature-band-source-building.md#3xx4xx-band-initial-release-n0b00
• https://github.com/dotnet/source-build/blob/main/Documentation/feature-band-source-building.md#3xx4xx-band-servicing-n0b01

So saying you can only depend on baseline channel definitely limits things.

With how it may be landing, we could potentially have it so that the next minor can be built with the previous minor. The minor versions are essentially feature bands but with simpler darc channel flows, dedicated branching infrastructure, and less confusing numbering (in theory)

[tmds]

@marcpopMSFT can you include in the proposal what would be the distro package names for installing the latest SDK feature band, and the container tag names for the SDK image?

For example, it might be dotnet-sdk-11.0.2xx and mcr.microsoft.com/dotnet/sdk:11.0.2xx with literal x chars.