Skip to content

Maintainers: Development, pre release, stable release workflow

Jump to bottom
Tom Urbach edited this page Jul 8, 2021 · 2 revisions

How to release ... carefully

Releasing on github triggers actions on Zenodo and other repos and cannot easily be undone.

Version strings

The M.N.P package version string is single sourced in fitgrid/__init__.py. The setup.py, conda meta.yaml, and sphinx docs pick it up from there.

  • Stable release versions are Major.Minor.Patch, e.g., __version__ = "0.5.0"
  • Subsequent development versions increment the Patch and then increment the .devX extension for each conda package pre-release until the next stable M.N.P release: 
    __version__ = "0.5.0"  # main branch, tagged release v0.5.0  
__version__ = "0.5.1.dev0"  # dev branch, pre-release  
__version__ = "0.5.1.dev1"  # dev branch pre-release  
__version__ = "0.5.1.dev2"  # dev branch pre-release  
__version__ = "0.5.1"  # main branch, tagged release v0.5.1

Development-Pre-release cycle

Always develop on a working branch, not dev or main

When starting a new working branch, branch from dev not main

When the local working branch is ready for CI testing ...

  1. Verify black --check -l 79 -S, pytests pass, and sphinx docs build locally
  2. Push the working branch to github
  3. Check the Actions CI pass ... pytests pass, sphinx docs build

When the working branch is ready for conda package pre-release ...

  1. Check binder builds (if not see Fix binder)

  2. Verify that the .devX of the M.N.P.devX version string increments the latest .devX on the pre-release label:

    https://anaconda.org/kutaslab/fitgrid/files

  3. Do steps 1 -3 for CI testing

  4. Check the CI all passes

  5. Pull the working branch to dev branch

  6. Verify the conda package tarball files uploaded to anaconda.org

Lather rinse repeat 1-10 for until ready for next stable release.

Stable release

Note: If there have been relevant code changes or updated package dependencies in the conda environment the binder Demo.ipynb on branch main may break. See Fix binder demo for what to do before the stable release.

Note: The exact form of the stable release version string M.N.P and matching vM.N.P are required to trigger deployment of the M.N.P packages to conda cloud and PyPI, and the docs to gh-pages

Note: You must be signed in to github and anaconda.org to check the Action logs and conda package uploads.

Each step here triggers Actions CI, make sure all pass before continuing.

  1. On dev branch w/ version M.N.P.devX, drop the .devX , e.g., 0.5.1.dev2 -> 0.5.1

    • Check Actions pass

  2. Pull branch dev to branch main

    • Check Actions pass

  3. Take a deep breath and create a new github stable release M.N.P with tag vM.N.P

Post-release TODOs:

  • Check Actions pass
  • Verify the M.N.P. conda package is on https://anaconda.org/kutaslab/fitgrid label main.
  • Edit the conda package description for the new upload.
  • Verify the M.N.P. package is on PyPI.
  • Verify the new docs are on https://kutaslab.github.io/fitgrid .
  • On branch dev, bump the development version string to the next Patch, e.g., after release v0.5.1, bump 0.5.1 to 0.5.2.dev0

Clone this wiki locally