Skip to content

Release management

Jump to bottom
Kenneth Hoste edited this page Jul 8, 2022 · 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 branch 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
      • update the counts in the headers
      • preview in readthedocs.io
      • update Changelog.rst and bump docs/conf.py
    • auto-update docs (make sure eb is using the release branch in all repos)

(to minimize time waiting for tests, once the release notes PR for each repo is merged, the PR to 'main' branch for that repo in the next step can be opened)

Release process

  • for repo in easybuild-framework easybuild-easyblocks easybuild-easyconfigs (in this order)

    • open PR to merge release branch (e.g. 4.1.x) into 'main' branch

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

    • create tags & push to GitHub; example:

      git fetch
git checkout main
git pull origin main
git status
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

    • create GitHub releases from tag

    • publish release on PyPI from main branch in clean checkout of repository, for example:

      ./easybuild/scripts/create_source_tarball.sh easybuild-framework 4.1.0
twine upload dist/easybuild-framework-4.1.0.tar.gz

  • 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

  • in easybuild repo (only after previous step was completed for all 3 repos):

    • merge develop into main
    • bump version in setup.py
    • publish release on PyPI repository
    • open PR to main (check that the version bumps and release notes commits are there)
    • merge PR to main
    • create release tags & push to GitHub

  • test pip install easybuild

    export PREFIX=/tmp/$USER/eb410
mkdir -p $PREFIX
pip install --prefix $PREFIX easybuild

  • if everything checks out: announce release

    • update news section on website (& remove entry for previous version), see https://easybuild.io 
      # 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 main & bump version to <next version>.dev0 (see also git log --patch easybuild/tools/version.py)

    git checkout main
git pull origin main
git checkout develop
git pull origin develop
git merge main 
# 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