Skip to content

[release/10.0.1xx] Allow default branding to be set by the VMR orchestrator#3668

Merged
ViktorHofer merged 1 commit intorelease/10.0.1xxfrom
DefineDefaultBrandingType1xx
Dec 4, 2025
Merged

[release/10.0.1xx] Allow default branding to be set by the VMR orchestrator#3668
ViktorHofer merged 1 commit intorelease/10.0.1xxfrom
DefineDefaultBrandingType1xx

Conversation

@ViktorHofer
Copy link
Member

Manual backport of f59b33b

@ViktorHofer ViktorHofer changed the title [release/10.0.1xx] Allow default branding to be set by the VMR orchestrator (#3574) [release/10.0.1xx] Allow default branding to be set by the VMR orchestrator Dec 3, 2025
@ViktorHofer
Copy link
Member Author

This is definitely tell-mode, infrastructure only change.

@ViktorHofer ViktorHofer merged commit b3d5bd3 into release/10.0.1xx Dec 4, 2025
10 of 11 checks passed
@ViktorHofer ViktorHofer deleted the DefineDefaultBrandingType1xx branch December 4, 2025 14:47
mmitche added a commit to mmitche/dotnet that referenced this pull request Dec 5, 2025
When dotnet#3668 went it, it removed DotNetFinalVersionKind from being set at the root level of the VMR. This unintentionally was causing the VMR publishing process to mark all shipping assets as CouldBeStable=true when DotNetFinalVersionKind=release, rather than using the values that were coming from the repos. The fix here is to not set PublishingVersion at the repo level. This will cause VMR builds to use V4 publishing for the repo builds, which will set CouldBeStable appropriately. Only winforms and wpf were manually setting this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants