Create maui specific runtime branch

[steveisok]

In order to align correctly with upcoming MAUI previews, we need to create a separate runtime branch and publish out of it.

• Create branch off of release/6.0. Suggestions on name of the branch are welcome (release/6.0-maui ?).
• Turn off stable branding
• Validate packages are building correctly
• Run official build

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In order to align correctly with upcoming MAUI previews, we need to create a separate runtime branch and publish out of it.

• Create branch off of release/6.0. Suggestions on name of the branch are welcome (release/6.0-maui ?).
• Turn off stable branding
• Validate packages are building correctly
• Run official build

Author:	steveisok
Assignees:	directhex
Labels:	area-Infrastructure
Milestone:	6.0.x

[steveisok]

@Anipik What are your thoughts on branding?

[steveisok]

/cc @mmitche

[mmitche]

release/6.0-maui sounds good to me.

[directhex]

So the existing version stuff on the release/6.0 branch reads

  <PropertyGroup>
    <!-- The .NET product branding version -->
    <ProductVersion>6.0.1</ProductVersion>
    <!-- File version numbers -->
    <MajorVersion>6</MajorVersion>
    <MinorVersion>0</MinorVersion>
    <PatchVersion>1</PatchVersion>
    <SdkBandVersion>6.0.100</SdkBandVersion>
    <PreReleaseVersionLabel>servicing</PreReleaseVersionLabel>
    <PreReleaseVersionIteration></PreReleaseVersionIteration>
  </PropertyGroup>

Do we just want to change PreReleaseVersionLabel and PreReleaseVersionIteration? And do we want something unique like mauipreview or are we gonna recycle the more generic preview text? I wouldn't want to use maui because that doesn't indicate that it's not stable. And I guess we need it to be alphabetically before servicing?

[ericstj]

cc @eerhardt @safern

What type of changes do you intend to make in this branch? Anything to libraries API or packages?

[eerhardt]

I'm a bit confused at having 2 "6.x" branches. Do we plan on actually "releasing" bits from this new branch? Or is it only to stage/develop changes that will eventually merge into the real release/6.0 branch? And we only "release" bits from release/6.0?

[steveisok]

What type of changes do you intend to make in this branch? Anything to libraries API or packages?

We should be making mostly bug fixes in this branch. We're going to have to ultimately run any changes we make through tactics.

It's my understanding that the primary purpose of this branch is to release preview labeled artifacts aligned to MAUI previews. The previews may come out at a different cadence than what comes out of release/6.0. We're talking about the mono workload manifest and workload packs (e.g. runtime packs for Android, iOS/tvOS, and MacCatalyst).

[safern]

We did something similar on the past for blazor on 3.1, where we had release/3.1-blazor.

And I guess we need it to be alphabetically before servicing

Maybe we could publish to a different feed that only maui uses? Or that doesn't work?

@steveisok do we need to publish OOB packages or only runtime and ref packs?

[steveisok]

Maybe we could publish to a different feed that only maui uses? Or that doesn't work?

I think the preview labeling will give enough isolation where we don't need a separate private feed. These preview nugets will make it to nuget.org whenever a public maui preview happens.

@steveisok do we need to publish OOB packages or only runtime and ref packs?

Good question. I think we may need to ship OOB packages too as it's possible we'll need to fix something.

[ericstj]

If that's the case, then you need to have a plan to integrate back into servicing, as well as have a plan for what ships when you do so (every package, or only those you change). We can't fork the versions of any asset that is shared between MAUI and the existing .NET 6 product.