@mmitche the PR is now ready. I also added a clear notice for distro maintainers that explicitly passed -branding rtm in for .NET 10 as they will need to react:

~/git/dotnet$ ./build.sh -branding rtm
Unsupported branding type 'rtm'.
The allowed values are repodefault, unstable, preview or release.

IMPORTANT: If you previously passed in the '-branding rtm' argument for .NET 10, remove it entirely. The default is now set correctly (VMR branding defaults for release branch builds or otherwise repo branding defaults).

@ellahathaway regarding https://dev.azure.com/dnceng/internal/_workitems/edit/8757, distro maintainers don't need to pass that argument in anymore as the default is now correct. Someone would only want to pass this argument in explicitly when wanting to change the default (i.e. testing stable builds in the RC timeframe) which is quite uncommon. Do we want to send out another announcement or update the existing one? We should wait though until the backport PRs are merged into 10.0.1xx and 10.0.2xx.

We should wait though until the backport PRs are merged into 10.0.1xx and 10.0.2xx.

I don't think we should backport this to 10.0.1xx as that would be a breaking change.

repodefault is the default behavior, when not stabilizing which means the repository decides the DotNetFinalVersionKind value. This is mainly used in the main branch and during RC1 before we switch to internal and stabilized builds.

When stabilizing for previews, RepoDotNetFinalVersionKind will get set to preview and for GA and servicing, the value will be release. These are different options because a preview still has a branding suffix (.final) vs release which doesn't have one.

unstable will be used to force non-stable assets in release branches. #3345 has more details on that.

I don't think we should backport this to 10.0.1xx as that would be a breaking change.

I really think we should backport to 1xx. The breaking change will be clearly visible (the build fails) and the error message indicates how to react. I want to include this as part of many UX build entry point changes that we did up to .NET 10 so that distro partners don't need to condition based on 1xx vs 2xx/main. cc @tmds for input

cc @dotnet/distro-maintainers for visibility

I don't think we should backport this to 10.0.1xx as that would be a breaking change.

I really think we should backport to 1xx. The breaking change will be clearly visible (the build fails) and the error message indicates how to react. I want to include this as part of many UX build entry point changes that we did up to .NET 10 so that distro partners don't need to condition based on 1xx vs 2xx/main. cc @tmds for input

@ViktorHofer - would it be feasible to support a migration? What I mean by that is for one servicing release we support both the new and old options so that folks can migrate at their convenience. Then the next servicing release we make the actual breaking change and remove the old options? I realize the transition period may be confusing with the option names but we could choose to support the old options as undocumented.

distro maintainers don't need to pass that argument in anymore as the default is now correct. Someone would only want to pass this argument in explicitly when wanting to change the default (i.e. testing stable builds in the RC timeframe) which is quite uncommon. Do we want to send out another announcement or update the existing one? We should wait though until the backport PRs are merged into 10.0.1xx and 10.0.2xx.

The announcement templates referenced in that work item served as a temporary workaround to address dotnet/release#1707 for the 10.0 GA release. As a result, the announcement templates were not permanently updated to include information about using the --branding argument. Since the long-term fix was implemented in dotnet/dotnet#3288, we now need to update the documentation accordingly. Once that's done, everything should be in order.

we now need to update the documentation accordingly. Once that's done, everything should be in order.

Ok. I was saying that with this change, distro partners don't need to pass --branding in anymore as the default is now correct. I think that means that we don't need to follow-up anywhere. This PR already updates the README.md

With my distro maintainer hat on, I never really understood the role of the branding argument. Requiring --branding rtm to build the right thing for 10.0 has been a bit surprising. I know some others were building wrong assets until they found about this argument and its purpose.

If this PR is switching to automatically building the right thing, then a big 👍 from me. I am even okay with the "build break" for 10.0 as this makes it easier to build the right thing correctly by default, and the error on using --branding rtm (the previous recommended value) seems clear and actionable.

If this PR is switching to automatically building the right thing, then a big 👍 from me

Yes, that's what this PR does 👍 While there's still the --branding switch, you would only want to pass that in for i.e. manual builds (locally or as a pipeline parameter) to use a different branding than what's chosen as the default for the given branch/SHA.