Release Management

The release management process for this repository is largely automated by build scripts though there are some manual actions and on confirmation for a final release.

Important

There are a lot of steps involved though many are automated. The POST-RELEASE nature of a CSemVer-CI and the BuildVersion.xml add complexity. This is an area where tooling can help simplify the process but does not yet exist to do so. If/when such tooling exists, this wiki should be updated to reflect the new patterns.

Starting a release

1. 'BuildVersion.xml' file is updated to the final release version (but NOT committed to any branch!).
   1. The reason it is updated is that it is read by the build scripts OneFlow\Start-Release.ps1 to know what branch name to use when creating the branches for the release.
   2. The reason it is NOT committed is that the release branch may have PR/CI builds and those MUST retain the base version of the release they are based on and NOT the soon to be released version.
      1. This is due to the fact that a CSemVer-CI build version is a POST-RELEASE version. It does NOT indicate what it will become, only what it was based on.
2. 'OneFlow\Start-Release.ps1' is run to create the release branches based on the current contents of 'BuildVersion.xml'

Updating for a release

1. Any changes needed for the release are applied to the created release branch...
   1. This step is repeated as often as needed, though it should not require much if any use. Significant activity here indicates that the release wasn't really ready to begin with.

Completing a release

1. BuildVersion.xml in the release branch is updated to reflect the final release version.
2. Changes to BuildVersion.xml are committed to the release branch and pushed to the official repository.
3. OneFlow\Publish-Release.ps1 is used to complete the release which does several things.
   1. Confirms intent to publish
      1. This is important to ensure the buildversion.xml was updated correctly. As of this writing the scripts don't verify the branch matches the contents of BuiildVersion.xml. (They can't as they use the file to get or create the branch!)
   2. Creates a tag to refer to the current state of the branch in perpetuity
   3. Pushes the version tag to the official repo
      1. This triggers the official build based on the tag reference
      2. Official build will build the binaries
      3. Official build will publish Built NuGet Packages to NuGet
      4. Official build will build the docs
      5. Official build will commit and publish the docs for the release
   4. Merge-back branch is created to merge changes since creation of the release branch to the develop branch
      1. This will at least contain the change to the BuildVersion.xml file
   5. Adjust main branch to refer to the tag of this release
      1. This allows easy access to latest release source via the main branch of the repository.
      2. This triggers the final release build based on that tag
   6. Creates a GH release in Draft form to allow customization 1) The release contains the generated NuGet Packages and source as a ZIP file
4. From the GH site create a PR for the merge back branch from the forked repository to the official develop branch.
   1. Resolve any merge conflicts
   2. Complete the PR
5. From GH official repo publish the release created by the script (see step 3.6)
   1. This is either a pre-release or set as the latest full release