For additional documentation see the Developer Guide: Release Management page. This file gives a brief reminder of what maintainers need to do for new releases.
- create a release on GitHub using tag
<major>.<minor>.<patch>
. - release on PyPi under https://pypi.org/project/GridDataFormats
- release on conda-forge https://anaconda.org/conda-forge/griddataformats
-
We use semantic versioning MAJOR.MINOR.PATCH (i.e., briefly, major revision changes whenever the API changes in backwards-incompatible manner, MINOR changes for new features, PATCH changes for fixes that correct functionality; as long as MAJOR == 0, we can break the API with increasing MINOR.)
-
Releases are cut from the master branch and tagged with MAJOR.MINOR.PATCH (note: the release tag determines the tag because we use versioneer, which obtains the release number from the git tag). We do from the master branch:
git tag <major>.<minor>.<patch>
git push --tags
-
Create a GitHub release from the tag and name it
v<major>.<minor>.<patch>
and add a short description.
Upload to PyPi can be done by PyPi maintainers and requires twine
:
python setup.py sdist bdist_wheel
twine upload dist/*
After a PyPi release update the conda-forge package. For this do the following on a local checkout of the package feedstock
- create a new branch
- conda smithy rerender
- update the sha256 in the
meta.yaml
(see the PyPi downloads page for the sha256 of the tar.gz file) - update version number
Afterwards upload the new branch to your own fork of the feedstock and generate a PR. Once all tests pass merge the PR and the package will be published.
Don't. We don't have the man power to update all the dependencies we need in the channel ourselves. Relying on conda-forge is more reliant.
Documentation is automatically generated on Travis CI and pushed to the gh-pages branch and appears at https://www.mdanalysis.org/GridDataFormats/.
There is also alternative documentation on ReadTheDocs https://griddataformats.readthedocs.io/, which automatically rebuilds.