[daniel-dumitrascu]

Summary

Adds a way to build a stable UiPath.Workflow and UiPath.Workflow.Runtime release, from a release/s<sprint> branch and only after an approval. Today only main builds without the -<build number> suffix, and main hasn't been updated since 2022 (6.0.3). Both packages always build together, with the same version: UiPath.Workflow depends on the exact UiPath.Workflow.Runtime of the same build.

A stable release is 6.0.0.<sprint>, e.g. 6.0.0.206 from release/s206. Normal builds keep today's versions (6.0.0-yyyyMMdd-NN, and 6.0.0 on main), and src/Directory.Build.props is unchanged.

Changes

• azure-pipelines.yaml: a Build and publish a stable release (release/s<sprint> only) checkbox, off by default. When it's ticked, a new ApproveStableRelease stage runs first and BuildAndTest depends on it, so nothing builds until someone approves on the CoreWFStableRelease environment.
  • The approval job only exists on release/s*. On any other branch, the stage fails right away without asking for an approval.
  • ReleaseInternal and ReleasePublic are unchanged and already require succeeded(), so a rejected approval stops the run before anything is published.
• .pipelines/build.yaml, only when the box is ticked:
  • The version is the Version from src/Directory.Build.props plus the sprint of the branch as a fourth number: 6.0.0.206 on release/s206. The branch must be exactly release/s<sprint>; anything else, such as release/s206_staging, fails.
  • dotnet test also gets /p:AssemblyVersion=6.0.0.0, the assembly version a normal build of Version 6.0.0 has. Without it, the SDK would take the four numbers of the version, and the DLLs would be 6.0.0.206.
  • The build is tagged stable-<version>.

ReleaseInternal pushes the stable packages to UiPath-Internal, the same way it pushes every release-branch build today.

Why 6.0.0.<sprint>

• The assembly version stays 6.0.0.0. Studio and the Robot ship UiPath.Workflow.dll and System.Activities.dll as 6.0.0.0, and the Robot always runs a process with its own copy of them. A package compiled against a higher assembly version can't be loaded there. That's what happened with 6.0.1 to 6.0.3 on nuget.org, whose DLLs are 6.0.1.0 to 6.0.3.0.
• No clash with nuget.org. 6.0.0 to 6.0.3 already exist there (unlisted, from 2022). A four-part version is never one of them.
• No version bump. Every release/s<sprint> branch has its own number, so Version stays 6.0.0.
• Ordering: NuGet treats a four-part version as stable: 6.0.0-<build> < 6.0.0 < 6.0.0.206 < 6.0.0.207 < 6.0.1.

One stable per release branch: a second stable run on the same branch builds the same version, and its push fails because UiPath-Internal already has it.

Required before merging: Azure DevOps environment

Create CoreWFStableRelease in the CoreWF project. There are no environments there yet, and the pipeline preview fails with "Environment CoreWFStableRelease could not be found" until it exists. Add two checks:

• Approval: the CoreWF owners (@aoltean16, @vuplea) or a group of your choice. A timeout of about 1 day is suggested.
• Branch control: refs/heads/release/*, refs/tags/uipath.package-signing.*. Branch control checks every repository resource of the run. This pipeline's only other repository, templates, is pinned to a uipath.package-signing tag, so that pattern has to be allowed too. With it, the branch rule is also enforced server-side.

How to use it

1. Cut a release/s<sprint> branch from develop after this PR is merged, for example release/s206. The existing release/s184 doesn't have this change.
2. Run the UiPath.CoreWF pipeline on it with the checkbox ticked, and approve Approve stable release.
3. ReleaseInternal publishes UiPath.Workflow and UiPath.Workflow.Runtime 6.0.0.206 to UiPath-Internal.

Effect on normal builds

• None: develop, release, support, PR and main builds keep the same version and the same stages. The version script only gains the stable block, which doesn't run when the box is unticked.
• Pre-releases built after a stable sort below it, e.g. 6.0.0-20261201-01 < 6.0.0.206, and a package that requires 6.0.0.206 or higher won't accept them. Consumers pin exact versions, as they have since 2022, when every build already sorted below nuget.org's 6.0.3.
• The stable UiPath.Workflow still depends on Roslyn 4.13.0-3.24620.4, like every build today. NuGet reports this as warning NU5104, not as an error.

Testing

• Pipeline preview:
  • Unticked, on this branch: the same stages, jobs, steps and conditions as develop. The only differences are the stable parameter and the stable block of the version script, which compiles to if ("False" -eq "True").
  • Ticked, on this branch: ApproveStableRelease comes first and expands to the fail-fast job, and BuildAndTest depends on it. dotnet test has /p:AssemblyVersion="$(AssemblyVersion)", and the version script runs the stable block.
  • With the branch condition forced to true, the approval job compiles and stops only at "Environment CoreWFStableRelease could not be found".
• Version script, run locally in Windows PowerShell 5.1:
  • stable on release/s206: 6.0.0.206, AssemblyVersion 6.0.0.0, tag stable-6.0.0.206; on release/s184: 6.0.0.184
  • stable on release/s206_staging, release/s0206, release/s0, release/s, release/foo, develop, support/25.10 or main: fails
  • unticked on develop, release/s206, support/25.10, a PR or main: the same output as develop's script (6.0.0-20261104-01, and 6.0.0 on main)
• Local build of both packages with SDK 8:
  • Stable: UiPath.Workflow 6.0.0.206 depends on UiPath.Workflow.Runtime 6.0.0.206. UiPath.Workflow.dll, System.Activities.dll and System.Xaml.dll have AssemblyVersion and FileVersion 6.0.0.0, and product version 6.0.0.206+<commit>.
  • Normal: 6.0.0-20261104-01, DLLs 6.0.0.0, the same as today.
  • Stable without the AssemblyVersion argument: System.Activities.dll is 6.0.0.206, which is why the pipeline passes it.
• Not run end to end. That needs the environment and a release/s<sprint> run after merge.

Jira

https://uipath.atlassian.net/browse/STUD-68110

🤖 Generated with Claude Code