How to Make a Release

A core developer should use the following steps to create a release X.Y.Z of hdmf.

Note

Since the hdmf wheels do not include compiled code, they are considered pure and could be generated on any supported platform.

That said, considering the instructions below have been tested on a Linux system, they may have to be adapted to work on macOS or Windows.

Prerequisites

All CI tests are passing on GitHub Actions.
You have a GPG signing key.
Dependency versions in requirements.txt, requirements-dev.txt, requirements-opt.txt, requirements-doc.txt, and requirements-min.txt are up-to-date.
Legal information and copyright dates in Legal.txt, license.txt, README.rst, docs/source/conf.py, and any other files are up-to-date.
Package information in setup.py is up-to-date.
README.rst information is up-to-date.
The hdmf-common-schema submodule is up-to-date. The version number should be checked manually in case syncing the git submodule does not work as expected.
Documentation reflects any new features and changes in HDMF functionality.
Documentation builds locally.
Documentation builds on the ReadTheDocs project on the “dev” build.
Release notes have been prepared.
An appropriate new version number has been selected.

Documentation conventions

The commands reported below should be evaluated in the same terminal session.

Commands to evaluate starts with a dollar sign. For example:

$ echo "Hello"
Hello

means that echo "Hello" should be copied and evaluated in the terminal.

Publish release on PyPI: Step-by-step

Make sure that all CI tests are passing on GitHub Actions.
List all tags sorted by version.

$ git tag -l | sort -V

Choose the next release version number and store it in a variable.

$ release=X.Y.Z
Warning

To ensure the packages are uploaded on PyPI, tags must match this regular expression: ^[0-9]+.[0-9]+.[0-9]+$.

Download the latest sources.

$ cd /tmp && git clone --recurse-submodules git@github.com:hdmf-dev/hdmf && cd hdmf

Tag the release.

$ git tag --sign -m "hdmf ${release}" ${release} origin/dev
Warning

This step requires a GPG signing key.

Publish the release tag.

$ git push origin ${release}
Important

This will trigger the “Deploy release” GitHub Actions workflow which will automatically upload the wheels and source distribution to both the HDMF PyPI project page and a new GitHub release using the hdmf-bot account.

Check the status of the builds on GitHub Actions.
Once the builds are completed, check that the distributions are available on HDMF PyPI project page and that a new GitHub release was created.
Copy the release notes from CHANGELOG.md to the newly created GitHub release.
Create a clean testing environment to test the installation.

On bash/zsh:
$ python -m venv hdmf-${release}-install-test && \
  source hdmf-${release}-install-test/bin/activate
On other shells, see the Python instructions for creating a virtual environment.

Test the installation:

$ pip install hdmf && \
  python -c "import hdmf; print(hdmf.__version__)"

Cleanup

On bash/zsh:

$ deactivate && \
  rm -rf dist/* && \
  rm -rf hdmf-${release}-install-test

Publish release on conda-forge: Step-by-step

Warning

Publishing on conda requires you to have the corresponding package version uploaded on PyPI. So you have to do the PyPI and GitHub release before you do the conda release.

Note

Conda-forge maintains a bot called “regro-cf-autotick-bot” that regularly monitors PyPI for new releases of packages that are also on conda-forge. When a new release is detected, usually within 24 hours of publishing on PyPI, the bot will create a Pull Request with the correct modifications to the version and sha256 values in meta.yaml. If the requirements in setup.py have been changed, then you need to modify the requirements/run section in meta.yaml manually to reflect these changes. Once tests pass, merge the PR, and a new release will be published on Anaconda cloud. This is the easiest way to update the package version on conda-forge.

In order to release a new version on conda-forge manually, follow the steps below:

Store the release version string (this should match the PyPI version that you already published).

$ release=X.Y.Z

Fork the hdmf-feedstock repository to your GitHub user account.
Clone the forked feedstock to your local filesystem.

Fill the YOURGITHUBUSER part.
```
$ cd /tmp && git clone https://github.com/YOURGITHUBUSER/hdmf-feedstock.git
```
Download the corresponding source for the release version.

$ cd /tmp && \
  wget https://github.com/hdmf-dev/hdmf/releases/download/$release/hdmf-$release.tar.gz

Create a new branch.

$ cd hdmf-feedstock && \
  git checkout -b $release

Modify meta.yaml.

Update the version string (line 2) and sha256 (line 3).

We have to modify the sha and the version string in the meta.yaml file.

For linux flavors:

$ sed -i "2s/.*/{% set version = \"$release\" %}/" recipe/meta.yaml
$ sha=$(openssl sha256 /tmp/hdmf-$release.tar.gz | awk '{print $2}')
$ sed -i "3s/.*/{$ set sha256 = \"$sha\" %}/" recipe/meta.yaml

For macOS:

$ sed -i -- "2s/.*/{% set version = \"$release\" %}/" recipe/meta.yaml
$ sha=$(openssl sha256 /tmp/hdmf-$release.tar.gz | awk '{print $2}')
$ sed -i -- "3s/.*/{$ set sha256 = \"$sha\" %}/" recipe/meta.yaml

If the requirements in setup.py have been changed, then modify the requirements/run list in the meta.yaml file to reflect these changes.

Push the changes to your fork.
```
$ git push origin $release
```
Create a Pull Request.

Create a pull request against the main feedstock repository. After the tests pass, merge the PR, and a new release will be published on Anaconda cloud.