mirror of
https://github.com/OPCFoundation/UA-.NETStandard.git
synced 2026-10-17 05:11:13 +08:00
Copilot
fd360271d9
# Description
**Target: `release/2.0`, squash merge.** This is step 4 of [First stable
release](docs/ReleaseProcess.md#first-stable-release). It removes the
preview suffix so the next `release/2.0` build produces the stable
`2.0.0` package set.
- **`version.json`**
- `"version"`: `2.0.0-preview.{height}` → `2.0.0`.
- `versionHeightOffset`: `-32` → `0`. NBGV still adds the offset to git
height for the file-version revision when `{height}` is absent. With
`-32`, the revision is negative and `nbgv get-version` throws in
`System.Version..ctor`.
- **`preview-version.props`**
- `PreviewPackageBuildNumber`: `100` → `200`. This number sets the
`-preview.N` suffix of the package families that stay in preview.
- `master` already pushes those packages to GitHub Packages as
`2.0.0-preview.88.g…`, and the number keeps rising. nuget.org's highest
is `2.0.0-preview.6`.
- With 100, the release would soon sort below master's builds.
`validate-preview-package-ordering.ps1` still checks the ordering when
the candidate is built.
With `--public-release=true`, nbgv 3.10.94 reports `NuGetPackageVersion`
`2.0.0` and `AssemblyVersion` `2.0.0.0`.
The branch started from `master`, so it carries a merge of the
`release/2.0` tip. The diff against `release/2.0` is only the two files
above.
**After merge:** run [Candidate and dry
run](docs/ReleaseProcess.md#candidate-and-dry-run); the manifest should
show `basePackageVersion: 2.0.0` and `channel: stable`. Then run
[Approved promotion](docs/ReleaseProcess.md#approved-promotion) with
`release.yml` and `channel=stable`. Advance `master` to
`2.1.0-preview.{height}` if not done yet. Then reopen `release/2.0` as
`2.0.1-preview.{height}`.
## Related Issues
None. This is a version-only release change.
## Checklist
_Put an `x` in the boxes that apply. You can complete these step by step
after opening the PR._
- [ ] I have signed the
[CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf)
and read the
[CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md)
doc.
- [ ] I have added tests that prove my fix is effective or that my
feature works and increased code coverage.
- [ ] I have added all necessary documentation.
- [ ] I have verified that my changes do not introduce (new) build or
analyzer warnings.
- [ ] I ran **all** tests locally using the **UA.slnx** solution against
at least .net **framework** and .net **10**, and all passed.
- [ ] I fixed **all** failing and flaky tests in the CI pipelines and
**all** CodeQL warnings.
- [ ] I have addressed **all** PR feedback received.
---------
Co-authored-by: romanett <romanett98@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Klaus Landsdorf <kl@iniationware.com>
Co-authored-by: Marc Schier <marcschier@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: marcschier <11168470+marcschier@users.noreply.github.com>
Co-authored-by: romanett <7413710+romanett@users.noreply.github.com>
41 lines
2.2 KiB
XML
41 lines
2.2 KiB
XML
<Project>
|
|
<!--
|
|
Numbers the "-preview.N" suffix that version.targets appends to the
|
|
preview-only package families (see ApplyPreviewPackageVersion) whenever
|
|
the root package version is an exact stable release, such as "2.0.0" on
|
|
release/2.0 at the moment the release is cut. That root version carries
|
|
no prerelease tag of its own at that point, so there is no git-height
|
|
placeholder available to derive a number from; this property supplies an
|
|
explicit, auditable one instead.
|
|
|
|
This is a manually curated release value, not a computed one:
|
|
* It MUST sort strictly above every already-published "-preview.N" (or
|
|
legacy "-preview.YYYYMMDD") identifier for the same "OPCFoundation.
|
|
NetStandard.Opc.Ua.*" package IDs on both nuget.org and the GitHub
|
|
Packages feed, including every ".Debug" package variant. Note that
|
|
ordinary development keeps publishing "<base>-preview.{height}"
|
|
packages with a monotonically growing height, so a value that was
|
|
correct when it was picked goes stale on its own.
|
|
.azurepipelines/validate-preview-package-ordering.ps1 proves this
|
|
invariant against both feeds and fails the stable candidate build and
|
|
the release promotion when it no longer holds; the value below is a
|
|
headroom estimate, and that check - not this comment - is what
|
|
guarantees correctness.
|
|
* It is reset/re-picked independently for every new stable base version
|
|
(2.0.0, 2.0.1, 2.1.0, ...); do not carry a prior release's value
|
|
forward without checking published versions again.
|
|
* See docs/ReleaseProcess.md ("Common preflight" and the per-release
|
|
procedures) for the exact commands used to look up the currently
|
|
published preview numbers before changing this value.
|
|
|
|
While the root version itself is still a prerelease (for example
|
|
"2.0.0-preview.{height}" during ordinary development, or
|
|
"2.0.1-preview.{height}" while release/2.0 is stabilizing the next
|
|
patch), version.targets reuses that prerelease tag directly and this
|
|
property has no effect.
|
|
-->
|
|
<PropertyGroup>
|
|
<PreviewPackageBuildNumber Condition="'$(PreviewPackageBuildNumber)' == ''">200</PreviewPackageBuildNumber>
|
|
</PropertyGroup>
|
|
</Project>
|