ci: Publish from servicing/* branches and bump main to 8.0-dev - #3173
Merged
Conversation
A servicing/* branch continues a previous version line after main has moved on to a newer one, so it needs to build and publish dev packages the same way main does. Adds servicing/* to the build and PR triggers, the Publish_Dev stage condition, the dev-feed push step and the NBGV publicReleaseRefSpec. Every change is an additional branch pattern inside an existing or(), so main's own behaviour is unchanged.
Matches the comments the other repos carry, so the pattern is discoverable from the files that decide whether a branch publishes.
'Validate for conventional commits' is a required status check on main, so it must also report for PRs into a servicing branch -- otherwise applying main's branch protection to servicing/* leaves those PRs stuck on a check that never runs.
Frees the 7.4-dev version space for servicing/7.4, which keeps publishing packages for the previous Uno line. Without a bump both branches would compute the same NBGV height and publish the same version from different code. Taken as a major because the 7.0 line drops net9.0 -- every published asset is currently net9 -- and removes the Mac Catalyst target framework, both breaking changes by .NET convention regardless of API surface.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GitHub Issue (If applicable): #
PR Type
What is the current behavior?
mainis the only branch that publishes an Extensions dev channel (7.4.0-dev.*). Oncemainretargets to Uno 7.0, those packages stop being consumable by apps still on Uno 6.x — which is what clients validate fixes against before we backport them to a service release.servicing/*is not wired into this pipeline, so cutting such a branch today produces a branch that builds nothing.What is the new behavior?
Four commits that must land together.
1.
ci: Build and publish from servicing/* branchesservicing/*intrigger.branchesandpr.branches(build/ci/.azure-pipelines.yml)servicing/in thePublish_Devstage conditionservicing/in the dev-feed push step (build/ci/templates/nuget-publish-dev.yml)main^refs/heads/servicing/.*$inpublicReleaseRefSpec(version.json)7.4.0-dev.30rather than7.4.0-dev.30.g8548c462cd2.
ci: Document the servicing/* branch pattern at the publish gates— the two generic comment blocks the other repos carry.3.
ci: Validate conventional commits on servicing/* branches—Validate for conventional commitsis a required status check onmain, but the workflow only listens for PRs tomainandrelease/*. This is a prerequisite for givingservicing/*the same branch protection: a required check that never reports leaves the PR stuck at "Expected — waiting for status".4.
chore!: Bump version to 8.0-dev for the Uno 7.0 lineWhy the bump is required
mainis at7.4.0-dev.29. Aservicing/7.4branch sits one commit above the same base, so both would compute7.4.0-dev.30from different code. The push runs withallowPackageConflicts: true, so the second is skipped silently on a green pipeline.Verified with
nbgv get-versionafter these commits:servicing/7.47.4.0-dev.30— clean, no hash suffix, confirming the refspec entry worksmain(this PR)8.0.0-dev.1— height resets at the version changeNo
8.0line exists on nuget.org today, so the space is free.Why a major
Unlike
Uno.Themesanduno.toolkit.ui— both already on net10, where the bump rested on binary compatibility alone — every trigger applies here. Read from the published7.4.0-dev.29package:net9.0-maccatalyst18.0is a shipped asset.-android/-iosassets become Skia binaries, unusable by 6.x consumers.7.0 work still ahead on this repo (not in this PR)
net9.0is hardcoded insrc/tfms-non-ui.props,src/tfms-ui-maui.propsand siblings (22 references).Uno.Extensions.Maui.WinUI.csprojplatform condition andsrc/Directory.Build.props.Microsoft.Maui.Controls.Compatibility— referenced by two shipped projects,Uno.Extensions.Maui.UIandUno.Extensions.Maui.WinUI.Markup. That package is no longer built or shipped as of .NET 11 Preview 6, which is whatunoplatform/uno#24360addressed on the SDK side. Someone should confirm MAUI embedding behaves on net11 without the compatibility renderers.Uno.UI.Toolkitreference to remap.No removed XAML prefixes, no SkiaSharp usage, no references to packages 7.0 deletes.
PR Checklist
!marks the version-line break for consumers of the 7.0 lineOther information
servicing/7.4is deliberately not pushed yet. It is cut at this PR's merge-base and stays local until this merges — pushing first opens the7.4.0-dev.30collision above. Its CI files are already byte-identical to this branch, so the two will not conflict on a later sync.Sequence: merge this, confirm
mainpublishes8.0.0-dev.1, pushservicing/7.4, confirm7.4.0-dev.30, then apply theservicing/*branch protection mirroringmain.Same pattern already merged in
unoplatform/uno#24361,uno.csharpmarkup#904,uno.app-mcp#143,Uno.Themes#1713anduno.toolkit.ui#1634.