-
Notifications
You must be signed in to change notification settings - Fork 22
Release Procedure
This wiki describes how to create/submit a new release of the ExoCTK package.
The ExoCTK team performs a software "release" at the end of each fiscal year quarter. In this context, the term "release" means the following:
- Creating a new branch for changes related to the version release procedure
- Updating the version number in
setup.py - Updating the
CHANGELOG.mdfile - Ensure that the release works in the ExoCTK web app
- Opening/reviewing/merging pull requests with the release changes
- Iterate with the Release Control Manager
- Creating of a new tag/release on GitHub
- Push the newly created tag/release to
upstream - Upload the newly created tag/release to PyPI
Detailed instructions for performing a release are given below.
Make sure that the local version of the develop branch is up-to-date. A new branch with the naming convention vx.y.z should be opened off of the develop branch, where x.y.z is the version number of the release (e.g. v1.2.0). This branch should be used for the changes described in the rest of this document.
The version variable in the setup() function in setup.py should be updated to the new version number, using the x.y.z convention.
In CHANGELOG.md, write a concise but detailed description of all of the notable changes that have occurred since the last release. One way to acquire this information is to scroll through the commit history of the project on GitHub, and look for commits in which a pull request was merged.
Log into the ExoCTK test server, pull the release branch, and restart the web app server to use the release branch. Make sure that the web app works as expected.
Once you've committed the changes from (2), (3), and (4) in your branch, push your branch to GitHub using the upstream remote, open two pull requests: one that points to master with the title "Release [master]", and one that points to develop with the title "Release [develop]. Assign reviewers. Either you or the reviewer should eventually merge these pull requests. It is important to ensure that the continuous integration builds pass successfully.
Since ExoCTK is an officially supported package by the JWST mission, it is necessary to have changes to the master branch (i.e. new releases) be reviewed by the INS Release Control Manager (currently Patrick Ogle). The INS Release Control Manager is in place to make sure that releases are done in an orderly manner and at times that are not disruptive to ongoing activities, such as an active proposal cycle.
At this point in the release procedure, reach out to the Release Control Manager and share the release PR with them. Iterate with them on any changes necessary.
Once the pull request into master from (4) has been merged, click on the releases button on the main page of the exoctk repository, then hit the Draft a new release button. The Tag version should be the version number of the release, the Target should be master, the Release title should (also) be the version number of the release, and the Description should match that of the changelog entry in (4). Once all of that information is added, hit the big green Publish release button.
Once the new tag/release has been created, make a local copy of the tag with git checkout tags/<tag> -b <branchname> (e.g. git checkout tags/v1.0.0 -b 1.0.0) and then git push upstream <branchname> (e.g. git push upstream 1.0.0). This will ensure that the particular release will be available and easy to access as a branch.
While still on the branch described in step (6), create a distribution and upload it to the ExoCTK PyPI project (note that you will have to be an owner of the PyPI project to do this):
python setup.py sdist bdist_wheel
twine upload -u '<pypi_username>' -p '<pypi_password>' --repository-url https://upload.pypi.org/legacy/ --skip-existing dist/*