Creating a Version 2.x Release Locally

WARNING: THIS PAGE IS CURRENTLY UNDER CONSTRUCTION

This page describes how we create a new 2.x release of the TestCentric GUI, working on your own development machine.

Required Permissions

UNDER CONSTRUCTION

Milestone

In order to begin the release process, there should already be be a GitHub milestone named for the release, e.g. 2.0.0. 2.0.1, 2.2.0. The name is required to be the same as the release package version, with three components. Our scripts depend on this.

All closed and merged issues to be included in the release must be part of the milestone. Any remaining open issues should be transferred to the next milestone before beginning this process, since the milestone will eventually be closed by the script.

The milestone description will appear in the release that is created on GitHub. You should edit it to describe the release in general. Start the description with a blank line to separate it from generated text that will precede it in the release notes.

Update Local Branch

Before starting, all issues to be included in the release should have been closed and the code merged to main on GitHub. You need to pull and build it locally to ensure there are no problems and to create the packages for release.

checkout main
git pull
build -t BuildTestAndPackage --packageVersion VERSION`

The --packageVersion option creates packages for the specific version you are about to release. For VERSION, substitute the full package version, such as 2.1.0 or 2.2.0-beta1

Create the Draft Release

3. Create a draft release using the same version you originally specified for the previous command.

build -t CreateDraftRelease --packageVersion VERSION`

If necessary, you may run this step multiple times, changing the milestone content as needed. You may also edit the draft release on GitHub, but those changes will be overwritten if you rerun the CreateDraftRelease target.

Production Release

7. Create a PR for the release branch.

8. Wait for the CI build to complete successfully and then merge it. This will trigger a new build and produce a dev release on MyGet. The main branch now has all the changes from the release branch.

9. Go to the draft release on GitHub and click Publish. This will tag the release on main and trigger a final production build.

10. The production build uploads all packages to NuGet and Chocolatey and adds them as assets on the GitHub release. The milestone is closed and all the issues have comments added indicating the release in which they were resolved.

11. Update the Release Notes on the website.

12. Notify users of the new release.

Limitations

1. This process does not yet support milestones with a pre-release suffix, like 2.0.0-beta2. This will be a future enhancement.

2. The Release Notes on the website must currently be updated manually.

3. User notification is currently manual.