Creating a Version 2.x Release

WARNING: THIS PAGE IS CURRENTLY UNDER CONSTRUCTION

This page describes how we create a new 2.x release of the TestCentric GUI, starting at the point where all issues to be included in the release have been closed and the code merged to main. The current code in main serves as the basis for the release.

NOTE: If you are doing a version 1 release, see Creating a Version 1.x Release.

SEE ALSO: Creating a Version 2.x Release Locally

Required Permissions

UNDER CONSTRUCTION

Milestone

In order to begin the release process, there should already be be a 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.

NOTE: This process does not yet support pre-releases, like 1.5.0-beta2. Such releases would have to be done manually.

Release Branch Creation

We use a release branch to isolate the process of creating the release from more substantive changes like bug fixes and new features. Ideally, you should leave the main branch unchanged from the time the release branch is created until the new release is published in order to avoid a merge conflict later in the process. This is generally not a problem because the release process takes very little time.

1. Create a new local branch named "release-{milestone}", like release-2.2.0.

2. Make any changes needed for the release, add and commit them. Normally, no changes are needed. Any change of significance should have been done in a PR before starting the process.

3. Commit your changes, if any, and push the new branch, for example: git push -u origin release-2.2.0. An AppVeyor build is triggered. In case of failure, you may fix and repeat this step until it is successful.

4. The AppVeyor build creates a draft release on GitHub. Check it to see that all closed issues appear and that the text is correct. No assets have been added to the release at this point.

5. If necessary, repeat steps 2 through 4 on the release branch until everything is correct.

NOTE: If you update the milestone but don't make any local changes, you don't need to do a new push. Instead, use the AppVeyor menu option to re-run the same commit.

6. At a final step before merging the release branch into main, you may edit the draft release text in any way you like. This is useful if you want something to appear in the release notes but not in the milestone.

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.