Skip to content

Release management

Jump to bottom
Miguel Dias Costa edited this page Dec 3, 2019 · 25 revisions

Shortly before next release

  • revisit target date

    • aim for a release every ~6-8 weeks

  • determine version of next release

    • patch release (4.x.y -> 4.x.(y+1))
      • bug fixes + software updates
    • minor update release (4.x.y -> 4.(x+1).0)
      • (significant) enhancements, bug fixes, software updates
    • major update (4.x.y -> 5.0.0)
      • backwards-incompatible changes

  • update next release milestone to mention actual (final) version of next release

  • add new next release milestone

  • clean up milestones for next release

    • start focusing on bug fixes or important enhancements
    • move other issues/PRs to either 4.x or new milestone for next-next release

  • once develop is considered ready for release (except for unexpected bugs to fix), either:

    • start a new release branche from develop (if it does not exist yet) 
      git fetch origin
git checkout develop
git pull origin develop
git checkout -b 4.1.x
git push origin 4.1.x
    • update existing release branch with current develop (if it already exists) 
      git fetch origin
git checkout develop
git pull origin develop
git checkout 4.1.x
git merge develop
git push origin 4.1.x

Regression test

  • start regression test as soon as release branches are considered complete

  • keep an eye out for failures, open issues & follow up (fix for this release?)

  • if any problems pop up that warrant bug fixes, open a PR to target the release branch (4.1.x) rather than develop

Compose release notes

  • scan merged PRs since last release for missing/wrong labels and milestones
  • first in RELEASE_NOTES in each repository (except easybuild)
  • bump version in version.py in each repository (except easybuild)
  • target PRs to release branches 4.1.x
  • once those PRs are merged, in the easybuild repo:
    • also update easybuild/docs/Release_notes.rst
      • copy-paste from RELEASE_NOTES + fix syntax & formatting
      • preview in readthedocs.io
    • auto-update docs

Release process

  • open PRs to merge release branches (e.g. 4.1.x) into master in each repo

    • take into account that easyblocks repo may require PR in framework repo to be merged first (similar for easyblocks/easyconfigs)

  • merge PRs to master once test suites pass in Travis & GitHub CI

  • open PR to master to bump versions in setup.py (and docs/conf.py?) in easybuild repo, merge when tests pass

  • create release tags & push to GitHub for all 4 repos; example:

    git checkout master
git pull origin master
git log -n 2
git tag -a easybuild-framework-v4.1.0 -m "easybuild-framework version 4.1.0 (release notes are available at https://easybuild.readthedocs.io/en/latest/Release_notes.html)"
git push origin easybuild-framework-v4.1.0

  • publish releases on PyPI from master branch in clean checkout of repository, for example:

    git status | grep "working tree clean"
python setup.py sdist
twine upload dist/easybuild-framework-4.1.0.tar.gz
    • these must be done in order (framework - easyblocks - easyconfigs - easybuild)

  • open PR for easyconfig file for latest EasyBuild release (required for eb --install-latest-eb-release)

    • re-test eb --install-latest-eb-release after it gets merged
    • this can be done before publishing release for easybuild repo

  • re-test bootstrap script

    export PREFIX=/tmp/$USER/eb410
mkdir -p $PREFIX
cd $PREFIX
curl -O https://raw.githubusercontent.com/hpcugent/easybuild-framework/develop/easybuild/scripts/bootstrap_eb.py
MODULEPATH= PYTHONPATH= python bootstrap_eb.py $PREFIX

  • if everything checks out: announce release

    • update news section on website (& remove entry for previous version), see https://easybuilders.github.io/easybuild 
      # in easybuild repo
git checkout gh-pages
git pull origin gh-pages
vim index.html
git add index.html
git commit -m "EasyBuild v4.1.0"
git push origin gh-pages
    • EasyBuild mailing list
      • highlight important/major/noteworthy changes
      • overview of # contributors & merged PRs
      • info on updating
    • update channel message in Slack/IRC
    • Twitter

  • update release schedule at https://github.com/easybuilders/easybuild/wiki/Release-schedule

  • update OpenHPC component

Post-release

  • sync up develop branch with master & bump version to <next version>.dev0 (see also git log --patch easybuild/tools/version.py)

    git checkout master
git pull origin master
git checkout develop
git pull origin develop
git merge master 
# easybuild-framework
vim easybuild/tools/version.py
# easybuild-easyblocks
vim easybuild/easyblocks/__init__.py
# easybuild-easyconfigs
vim setup.py

git add <path>
git commit -m "bump version to <version>dev"

  • close release milestones (only when 100% complete!)

    • close or move any leftover issues/PRs to milestone next release)

  • set initial target date for next release

  • celebrate with a beer (or two)

Clone this wiki locally