Release process - openucx/ucx GitHub Wiki

Preparations

  1. Create release branch v<major>.<minor>.x
  2. Bump version of master branch
  3. Update NEWS on the release branch
    1. Mention items that affect user experience (feature/bugfix/enhancement), or key infrastructure changes
    2. Go over commit titles excluding merge commits since the previous release and add relevant items
    3. NEWS should be updated for every release candidate git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative fork<X-1>commit..branch<X>
    4. Add items from internal checklists, such as Plan-of-Record
    5. Tag key community members in the new PR to add/modify missing items
  4. Update Author list before release
    1. git log --pretty=format:"%an%x09%ae" | sort | uniq > AUTHORS.new
    2. since people use multiple email addresses and names we have to clean up the new file
      vimdiff AUTHORS.new AUTHORS
    3. or
git log --no-merges --pretty=format:"%an%x09%ae" fork<X-1>commit..HEAD | sort -u > AUTHORS.tmp
cat AUTHORS | grep @ >> AUTHORS.tmp
cat ./AUTHORS.tmp | sort -u > ./AUTHORS.new
cat ./AUTHORS | grep -v @ >> ./AUTHORS.new
vimdiff AUTHORS.new AUTHORS # <- remove duplicates 

Original release notes (can be deleted once we close on this one)

https://github.com/openucx/ucx/wiki/UCX-release-checklist

Publishing releases

  1. Go to Code->Releases
  1. Click Draft new release
  1. Set the release version, target branch, and mark as pre-release (for release candidate)
  1. Click Publish Release

  2. An automatic Azure pipeline will start building the packages (https://dev.azure.com/ucfconsort/ucx/_build?definitionId=5&_a=summary), please Do not touch the release page while the job is running. If CI has not been started it maybe needed to re-create tag.

  3. When step (5) finishes, there will be a new release page with all packages (9 Assets) attached to it

  4. Remove excess news from the release page

  5. Upload API documentation: (In the commands below replace {version} by 1.12 for example)

    • Make a clean checkout of the release branch
    • Install the packages doxygen and doxygen-latex. It's recommended to use fedora 30 or above.
    • ./autogen.sh
    • make docs
    • git checkout gh-pages
    • mkdir api/v{version}
    • ln -snf v{version} api/latest
      $ ll api
      lrwxrwxrwx 1 user group     5 Jan 13 14:54 latest -> v1.12`
    • cp docs/doxygen-doc/ucx.pdf api/v{version}/ucx-v{version}.pdf
    • ln -s ucx-v{version}.pdf api/v{version}/ucx.pdf
    • cp -ar docs/doxygen-doc/html api/v{version}/
      $ ll api/v1.12/
      drwxr-xr-x 3 user group       24576 Jan 13 14:38 html
      -rw-r--r-- 1 user group     1276888 Jan 13 14:45 ucx-v1.12.pdf
    • git add api/latest api/v{version}
    • git commit -m "add v{version} documentation"
    • git push ...
    • documentation needs to be rebuilt on readthedocsio
  6. Send an email to ucx-dev mailing list to announce the release

  7. Bump release version in configure.ac and ucx.spec.in (if another minor release is planned on this release branch)

Release candidates

  • NEWS file should contain separated section for every drop:
## 1.13.0-rc2 (DATE)
#### Bugfixes
* Bugfix 3
## 1.13.0-rc1 (DATE)
#### Features
* Feature 1
* Feature 2
#### Bugfixes
* Bugfix 1
* Bugfix 2
  • GA release drop should cointain single section, which is merge of all release candidates
## 1.13.0 (DATE)
#### Features
* Feature 1
* Feature 2
#### Bugfixes
* Bugfix 1
* Bugfix 2
* Bugfix 3
⚠️ **GitHub.com Fallback** ⚠️