simplify release branch to just 'release'#417
Conversation
- update publicReleaseRefSpec to match ^refs/heads/release$ - update RELEASE.md to reflect new branch strategy (no more alpha branches)
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Simplifies the release workflow by moving from versioned release/v* branches (and alpha branches) to a single release branch, updating Nerdbank.GitVersioning configuration and release documentation accordingly.
Changes:
- Update
publicReleaseRefSpecto treat onlyrefs/heads/releaseas a public release branch. - Remove alpha-branch workflow references and update release flow docs to
main → release. - Refresh examples in
RELEASE.mdto reflect the 2.0 stable line and current dev version.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.
| File | Description |
|---|---|
| version.json | Adjusts NBGV public release branch matching to a single release branch. |
| RELEASE.md | Updates the documented branching/versioning workflow and examples to match the simplified release strategy. |
| | `main` | `2.0.0.dev1`, `2.0.0.dev2`, ... | No | | ||
| | `alpha/v2.0.0` | `2.0.0a10`, `2.0.0a11`, ... | Yes | | ||
| | `release/v2.0.0` | `2.0.0` | Yes | | ||
| | `main` | `2.0.1.dev1`, `2.0.1.dev2`, ... | No | |
There was a problem hiding this comment.
The documented dev version examples use the PEP440-style 2.0.1.devN, but the shown version.json value is 2.0.1-dev.{height} (dash). Unless there’s a known translation step in your packaging pipeline, this is inconsistent and can mislead when validating with nbgv get-version. Align the examples with the actual versions produced in this repo (either update the examples to match NBGV output for -dev.{height}, or change the configured version string to the format you intend to document).
| ```json | ||
| { | ||
| "version": "2.0.0-dev.{height}", | ||
| "version": "2.0.1-dev.{height}", |
There was a problem hiding this comment.
The documented dev version examples use the PEP440-style 2.0.1.devN, but the shown version.json value is 2.0.1-dev.{height} (dash). Unless there’s a known translation step in your packaging pipeline, this is inconsistent and can mislead when validating with nbgv get-version. Align the examples with the actual versions produced in this repo (either update the examples to match NBGV output for -dev.{height}, or change the configured version string to the format you intend to document).
| ``` | ||
|
|
||
| Builds on `alpha/v2.0.0` produce alpha versions like `2.0.0a10`, `2.0.0a11`, etc. These are published. | ||
| Builds on `main` produce dev versions like `2.0.1.dev1`, `2.0.1.dev2`, etc. These are not published. |
There was a problem hiding this comment.
The documented dev version examples use the PEP440-style 2.0.1.devN, but the shown version.json value is 2.0.1-dev.{height} (dash). Unless there’s a known translation step in your packaging pipeline, this is inconsistent and can mislead when validating with nbgv get-version. Align the examples with the actual versions produced in this repo (either update the examples to match NBGV output for -dev.{height}, or change the configured version string to the format you intend to document).
| | `release` | `microsoft_teams_apps-2.0.0.tar.gz` | | ||
|
|
||
| > **Note:** Running the pipeline on a branch not in `publicReleaseRefSpec` (e.g., a feature branch) produces versions with the commit hash appended, like `2.0.0a11.dev5+g1a2b3c4`. This is expected and useful for testing. | ||
| > **Note:** Running the pipeline on a branch not in `publicReleaseRefSpec` (e.g., a feature branch) produces versions with the commit hash appended, like `2.0.1.dev5+g1a2b3c4`. This is expected and useful for testing. |
There was a problem hiding this comment.
The documented dev version examples use the PEP440-style 2.0.1.devN, but the shown version.json value is 2.0.1-dev.{height} (dash). Unless there’s a known translation step in your packaging pipeline, this is inconsistent and can mislead when validating with nbgv get-version. Align the examples with the actual versions produced in this repo (either update the examples to match NBGV output for -dev.{height}, or change the configured version string to the format you intend to document).
| @@ -41,38 +38,27 @@ Versions are managed by **Nerdbank.GitVersioning** via [version.json](version.js | |||
|
|
|||
There was a problem hiding this comment.
The doc now relies on publicReleaseRefSpec behavior (it’s referenced explicitly in the note), but the embedded version.json example omits publicReleaseRefSpec entirely. Since this PR changes that setting in a way that affects what becomes “public,” it would be clearer to either include publicReleaseRefSpec in the example JSON or add a short explanation describing that only refs/heads/release is considered public after this change.
| Development happens on `main`. When ready to release, create a `release` branch from `main`: | ||
|
|
||
| ``` | ||
| main → alpha/v2.0.0 → release/v2.0.0 | ||
| main → release |
There was a problem hiding this comment.
Moving to a single long-lived release branch has an operational tradeoff: it makes it harder to concurrently service multiple stable lines (e.g., hotfix 2.0.x after starting 2.1.x), because only one branch name matches publicReleaseRefSpec. Consider documenting an explicit policy for patch/hotfix releases (e.g., cut a maintenance branch and temporarily widen publicReleaseRefSpec, or use tags + a controlled process to publish from release), so future releases don’t require ad-hoc branching/publishing decisions.
| To produce a stable release (e.g., `2.0.0` without any suffix): | ||
|
|
||
| 1. Create a `release/v2.0.0` branch from `alpha/v2.0.0` | ||
| 1. Create a `release` branch from `main` |
There was a problem hiding this comment.
Moving to a single long-lived release branch has an operational tradeoff: it makes it harder to concurrently service multiple stable lines (e.g., hotfix 2.0.x after starting 2.1.x), because only one branch name matches publicReleaseRefSpec. Consider documenting an explicit policy for patch/hotfix releases (e.g., cut a maintenance branch and temporarily widen publicReleaseRefSpec, or use tags + a controlled process to publish from release), so future releases don’t require ad-hoc branching/publishing decisions.
| 1. Go to **Pipelines** > **teams.py** in ADO | ||
| 2. Click **Run pipeline** | ||
| 3. Select the branch to build from (e.g., `alpha/v2.0.0`) | ||
| 3. Select the `release` branch |
There was a problem hiding this comment.
Moving to a single long-lived release branch has an operational tradeoff: it makes it harder to concurrently service multiple stable lines (e.g., hotfix 2.0.x after starting 2.1.x), because only one branch name matches publicReleaseRefSpec. Consider documenting an explicit policy for patch/hotfix releases (e.g., cut a maintenance branch and temporarily widen publicReleaseRefSpec, or use tags + a controlled process to publish from release), so future releases don’t require ad-hoc branching/publishing decisions.
Summary
publicReleaseRefSpecin version.json to matchreleaseinstead ofrelease/v*Test plan
nbgv get-versionon areleasebranch produces clean version