Skip to content

Guide to Making A Release

Jump to bottom
Shannon Osborne edited this page Feb 4, 2020 · 12 revisions

This can probably be streamlined and automated...

Steps to follow:

Note, you probably will want to do all of the following for poppy (if making a poppy release), then after that's done, do all of the following for webbpsf.

  1. Pre-release checklist.
    1. Ensure the release notes have what you want in them,
    2. ensure all the issues you want closed are closed, and all the relevant PRs are merged,
    3. Update the data files, if necessary.
      1. If updating the webbpsf data files, do that using the scripts in webbpsf/dev_utils/master_data_release.sh.
      2. Unzip the resulting zip file someplace. Manually set $WEBBPSF_DATA_PATH to that. Test that stuff works.
      3. Update webbpsf/__init__.py to set DATA_VERSION_MIN to that version.
    4. check all the tests pass,
    5. And check the 'latest' docs on Readthedocs build successfully and have what you want.
  2. Optional: Create release branch and get ready to release, following http://nvie.com/posts/a-successful-git-branching-model/
    1. Dec 2018 update: I think this is an outdated idea and not necessary right now? We haven’t so far been keeping persistent open branches for each version.
  3. Do the following:
    1. git pull upstream # ensure you have latest master!
    2. Update version numbers
      1. git tag -a “v1.2.3" -m "Release 1.2.3" # This creates a local tag. Do not push it yet.
      2. For webbpsf, in the data file download URLs in docs/installation.rst
      3. PROBABLY UPDATE WEBBPSF’s setup.cfg TO DEPEND ON LATEST POPPY RELEASE TOO
    3. Run python setup.py clean
  4. Run python setup.py sdist
    1. This makes the ‘sdist’ zip file that will be uploaded to PyPI in a later step.
  5. Test installing from that file and make sure it works
    1. cd dist
    2. pip install <name of dist file>
    3. python
    4. >>> import poppy
    5. >>> print(poppy.__path__, poppy.__version__) # check these are as desired
    6. >>> poppy.test() # checks functionality of the installed package
    7. >>> quit
    8. cd ..
  6. Tag the release in git and Release on Github:
    1. git commit -m “Release 1.2.3" # If you already committed the update of version number above, this may be a null commit.
    2. git push upstream master
    3. git push upstream v1.2.3 # This pushes that one tag upstream
    4. Add a release via the Github web interface. See https://help.github.com/articles/creating-releases/
  7. Release the package on PyPI.
    1. You need to have accounts on both PyPI and TestPyPI. Register there if you haven't already. An owner (admin) of webbpsf and poppy will need to add you to the list of maintainers there.
    2. Ensure you have twine installed and set up. See https://pypi.org/project/twine/
    3. Upload a test file to TestPYPI: twine upload --repository-url https://test.pypi.org/legacy/ dist/*
    4. Look at test.pypi.org and verify things seem ok. https://test.pypi.org/project/poppy/ or https://test.pypi.org/project/webbpsf/
    5. Assuming the test does look good, run twine upload dist/*
  8. Release the updated docs
    1. Readthedocs should automatically build the latest docs from the push to GitHub. But verify this has taken place, and if necessary kick off a manual build.
  9. Release the package via Astroconda
    1. For the astroconda-contrib repository, submit a PR updating the poppy, webbpsf, and webbpsf-data versions appropriately
    2. See https://github.com/astroconda/astroconda-contrib/tree/master/poppy, https://github.com/astroconda/astroconda-contrib/tree/master/webbpsf, https://github.com/astroconda/astroconda-contrib/tree/master/webbpsf-data
    3. These very simple PRs can be done just via the Github web interface
  10. Now you're done with the release, but not quite done. Time to get back into development mode.
    1. Undo the installation of the sdist and get back to develop mode: python setup.py develop
    2. Edit setup.py and set the version number back to development mode for a higher-numbered release, e.g. "1.2.4dev"
    3. Commit that edit. Now you might be done.

Send a triumphant email to [email protected]! Brief is good - mention the highlights and link to the online doc release notes.

Clone this wiki locally