-
Notifications
You must be signed in to change notification settings - Fork 48
Release procedures
Releases are prepared on release branches. When done the branch is merged with the stable branch via a Pull Request (PR).
The example below creates a hypothetical release version 2.0.0.
Clone the repository on spacetelescope.
git clone [email protected]:spacetelescope/gwcs.git
-
Make last changes to the release branch. Edit CHANGES.rst to set the release date. If necessary make other code changes (there should be only minor changes at this point, if any).
-
Make sure you are on the master branch. Make a branch for the release. Name the branch 2.0.0x. Always use a letter at the end of the branch name so that the version number can be used later as a tag.
git status # should show you are on master.
git branch 2.0.0x
git checkout 2.0.0x
- Push the 2.0.0x branch to spacetelescope and create a PR to the stable branch. Note, that origin below refers to the spacetelescope repository.
git push origin 2.0.0x
- Checkout the stable branch and tag it with the new release.
git checkout stable
git tag -a "2.0.0" -m "tagging release 2.0.0"
git push origin 2.0.0
-
After CI tests pass merge the PR into stable.
-
Checkout the 2.0.0x branch and tag it with the new release.
git checkout 2.0.0x
git tag -a "2.0.0" -m "tagging release 2.0.0"
git push origin 2.0.0
Checkout master and tag it for further development. The suggested tag is the next version, followed by a. The tag name should be chosen in such a way that conda would resolve it as the latest tag. This allows the nightly build scripts to pick up the latest version from master.
git checkout master
git tag -a "2.1.0a" -m "tagging for further development"
git push origin 2.1.0a
-
Make a release on Github supplying the tag.
-
Release on PyPi
The release on PyPi happens automatically. After the Github release is done, the "Publish_to_PyPi" Github Action is triggered. It builds a releases and pushes it to PyPi.
- Alternative method of manually publishing to PyPI (skip if 2) worked).
Checkout the release tag.
git checkout 2.0.0
Clean the working directory and build the distribution package.
git clean -dfx
python setup.py build sdist
Test the distribution by going into the dist directory , unpacking and running the tests. Make sure the tests are run with the stable versions (publicly released versions) of astropy and asdf. If the tests pass with stable versions, proceed with the release.
Clean after the tests and build the distribution again. Sign the distribution and upload it to PYPI.
git clean -dfx
python setup.py build sdist
gpg --detach-sign -a dist/gwcs-2.0.0.tar.gz
twine upload dist/gwcs-2.0.0.tar.gz
- Go to https://pypi.python.org/ and ensure that only the most recent release is visible.
A bot on conda-forge creates a PR with changes to the recipe. If the changes look good and the PR tests pas, merge it into conda-forge.
If the automaticly created PR is not good, push changes manually before merging.
Clone (a fork of ) the gwcs-feedstock repository.
Branch for the new release and change the recipe. Edit the file recipe/meta.yaml to include the correct version number and SHA. The SHA can be obtained from the PYPI site. Click on the "Download" link and look for a link to the SHA near "Download files".
Submit a PR to https://github.com/conda-forge/gwcs-feedstock