Skip to content

Release okonomiyaki

Jump to bottom Edit New page
Ioannis Tziakos edited this page Nov 8, 2019 · 3 revisions

Release branch

Development work normally takes place on the master branch, while depending on the release type change logs and the release related commits can take place on master or the related maintenance branches.

  • Major release -- master branch
  • Minor release -- master branch.
  • Micro release -- takes place on the minor release maintenance/<majog>.<minor>.x branch.

Note

Micro releases should happen only for bugfixes.

(from https://semver.org/) 

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are 
introduced. A bug fix is defined as an internal change that fixes incorrect behavior.

Release PR

Note

  • There should always be only one commit in the repo for which the IS_RELEASED = True for a specific version.
  • All PRs are using squash and merge

Micro release

A micro release takes place always in a maintenance/<majog>.<minor>.x branch. So before making a minor release make sure that the necessary PRs commits are cherry-picked from the master branch onto the maintenance branch.

  1. Create a PR against the related maintenance branch.
  2. Update the changelog.
  3. Wait for the tests to pass and merge PR
  4. Create a new PR against the maintenance branch.
  5. (one commit) Set the IS_RELEASED constant in setup.py to True.
  6. Wait for the tests to pass and merge PR
  7. Create a new PR against the maintenance branch.
  8. (one commit) Bump the version to the next micro version and set IS_RELEASED constant in setup.py to False.
  9. Wait for the tests to pass and merge PR
  10. Tag the release commit (use git tag -a) and push the new tag to github.

Major/Minor release

Major and Minor releases take place in the master branch:

  1. Create a PR against the master.
  2. Update the changelog.
  3. Wait for the tests to pass and merge PR
  4. Create a new PR against the master branch.
  5. (one commit) Set the IS_RELEASED constant in setup.py to True.
  6. Wait for the tests to pass and merge PR.
  7. Create a new PR against the master branch.
  8. (one commit) Bump the version to the next minor version and set IS_RELEASED constant in setup.py to False.
  9. Wait for the tests to pass and merge PR.
  10. Tag the release commit (use git tag -a) and push the new tag to github.

Post release

As soon as a release has been approved. The following tasks need to take place.

  1. Copy the release notes in the the GitHub tag release notes.
  2. Update the on-line documentation.
  3. Send a release announcement.
  4. If release was a minor or major release create the related maintenance branch.
  5. If release was a micro release then create a PR to forward port the release note commits into master.

Update documentation

On a clean repo we checkout the release tag

rm -rf ./doc_staging
git clone --branch=gh-pages git@github.com:enthought/okonomiyaki.git doc_staging
python setup.py build_sphinx
cp -a build/sphinx/html/. ./doc_staging/
cd doc_staging

Then create a new branch commit the changes and push a PR to update the documentation against the gh-pages branch.

Add a custom footer
Add a custom sidebar
Clone this wiki locally