Release Process¶
This document describes the release workflow for Forge.
Overview¶
Releases follow a notes-first pattern: release notes land in main via PR, then the pipeline validates the build before the release branch is cut.
Steps¶
1. Create Release Notes¶
Use the /create-release Copilot prompt to generate release notes:
This will:
- Analyze commits since the last release tag
- Generate docs/release-notes/{version}.md and docs/release-notes/_announcements/{version}.md
- Create a release-notes/{version} branch and PR into main
2. Merge to Main¶
Review the release notes PR and merge it into main.
3. Run Pipeline¶
Run the CI/CD pipeline from main to validate the build.
4. Post Announcement¶
Post the content from docs/release-notes/_announcements/{version}.md to the #forge-releases Teams channel.
5. Create Release Branch¶
Cut the release branch from main:
git checkout main
git pull
git checkout -b releases/{major}.{minor}
git push -u origin releases/{major}.{minor}
The pipeline will create the release tag from this branch.
6. Bump Version on Main¶
Update .azdo/vars/vars.yml on main to increment MinorVersion for the next release:
variables:
- name: MajorVersion
value: 3
- name: MinorVersion
value: 5
- name: PatchVersion
value: 0
Commit and push directly or via PR. Only change MajorVersion when preparing a new major release.
Patch Releases¶
For patches against an existing release:
- Create a branch off
mainand fix the issue - Merge the fix to
main - Backport the fix using the
/create-backportprompt: This cherry-picks the commit, resolves conflicts, and creates a PR into the release branch. - Merge the backport PR into
releases/{major}.{minor} - Run
/create-release {patch-version}for the patch release notes and merge tomain - Run the pipeline off the
releases/{major}.{minor}branch to create the patch tag
Version Format¶
Forge uses semantic versioning: MAJOR.MINOR.PATCH (e.g., 3.4.0).
Version is defined in .azdo/vars/vars.yml as static values (MajorVersion, MinorVersion, PatchVersion).