From 5f6890dab367acdd011c9fcc1b41252fd4caf1be Mon Sep 17 00:00:00 2001 From: Kieron Lanning Date: Tue, 27 Oct 2026 14:54:02 +0000 Subject: [PATCH] chore: set the version to 1.0.0-prerelease.9 Release the Service Bus emulator work as the next 1.0 prerelease rather than a new minor line. Name release branches after the version (release/v1.0.9), the existing release/v1.0.8 convention, instead of release/.. --- AGENTS.md | 3 ++- docs/wiki/Release-Flow.md | 9 +++++---- package.json | 2 +- 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index e7293ab..b224567 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -191,7 +191,8 @@ Commit messages follow Conventional Commits enforced by the `commit-msg` lefthoo `purview-dev/build/.github/workflows/purview-build.yml`, with pack and validation enabled. - `.github/workflows/release.yml` runs the shared release pipeline with `release-mode: NuGet` on a push to a `release/**` branch (or a manual dispatch), **not** on a push to `main`. Cut a release by merging the - version bump into `main`, then pushing `release/.` from it. `.config/purview-build.json` + version bump into `main`, then pushing a `release/v…` branch named after the version from it (for + example `release/v1.0.9` for `1.0.0-prerelease.9`). `.config/purview-build.json` sets the `TrunkReservesMinor` eligibility policy; a version whose `v` tag already exists is skipped (`REL002`), so every release needs a new `package.json` version. See [Release Flow](docs/wiki/Release-Flow.md). diff --git a/docs/wiki/Release-Flow.md b/docs/wiki/Release-Flow.md index bbb3db1..d2a8199 100644 --- a/docs/wiki/Release-Flow.md +++ b/docs/wiki/Release-Flow.md @@ -62,15 +62,16 @@ and keep `purview-build.json` pointing at `src/Containers.slnx`. 1. Bump `version` in `package.json` on a branch (keep the `-prerelease.N` suffix), and merge it into `main` through a pull request. -2. Push a release branch for that version's `.` line from `main`, for example: +2. Push a release branch named after the version from `main`. The convention is `release/v..`, + where `N` is the prerelease number, for example `release/v1.0.9` for `1.0.0-prerelease.9`: ```bash git switch main && git pull - git push origin main:refs/heads/release/1.1 + git push origin main:refs/heads/release/v1.0.9 ``` -3. The Release workflow runs on that push. Further fixes for the same line are released by bumping - `package.json` again and pushing the `release/.` branch. +3. The Release workflow runs on that push. Each release is a new `package.json` version and a new + release branch. Check the decision locally before pushing with `dotnet tool run purview-build -- release-explain`. It runs nothing and publishes nothing; it reports the verdict and the rule that decided it. diff --git a/package.json b/package.json index 1cb9fb0..1d3d3e2 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "containers", - "version": "1.1.0-prerelease.1", + "version": "1.0.0-prerelease.9", "description": "Testcontainers-style library for .NET that runs throwaway Linux containers for integration testing, on Microsoft WSL Containers or Docker.", "license": "MIT", "author": {