Developer Notes: Releasing a new version of WebbPSF


Releasing new data packages

  1. Run dev_utils/ (details below) to make a gzipped tarred archive of the WebbPSF data

  2. If the new data package is required (meaning you can’t run WebbPSF without it, or you can run but may get incorrect results), you must bump DATA_VERSION_MIN in to (0, X, Y)

  3. Extract the resulting data archive and check that you can run the WebbPSF tests with WEBBPSF_PATH pointing to it

  4. Copy the data archive into public web space.

    1. This now means on Box. Upload to Box in the webbpsf shared data folder. Get the Box shared file URL.

    2. Update docs/installation.rst to have that new URL and updated filename in the appropriate location.

  5. Update the shared copy on STScI Central Store (DEPRECATED AS OF VERSION 1.2.0):

    1. cd to /grp/jwst/ote and remove the webbpsf-data symlink

    2. Copy the archive into /grp/jwst/ote/ and extract it to /grp/jwst/ote/webbpsf-data

    3. Rename the folder to webbpsf-data-0.x.y

    4. Create a symbolic link at /grp/jwst/ote/webbpsf-data to point to the new folder

  6. Update the URL in installation.rst under Installing the Required Data Files

Details for using

Invoke dev_utils/ one of the following ways to make a gzipped tarred archive of the WebbPSF data suitable for distribution.

If you are on the Institute network:

$ cd webbpsf/dev_utils/
$ ./ 0.X.Y
$ cp ./webbpsf-data-0.X.Y.tar.gz /path/to/public/web/directory/

If you’re working from a local data root:

$ cd webbpsf/dev_utils/
$ DATAROOT="/Users/you/webbpsf-data-sources/" ./ 0.X.Y
$ cp ./webbpsf-data-0.X.Y.tar.gz /where/ever/you/want/

Releasing new versions

If you are making a release for poppy at the same time as a release in WebbPSF, do that first. Update the dependency requirement to the new version of poppy, in ``webbpsf/pyproject.toml`.

When you are ready, proceed with the WebbPSF release as follows:

  1. Get the develop branch into the state that you want, including all PRs merged, updated release notes. This includes all tests passing both locally and on GitHub Actions.

  2. Tag the commit with v, being sure to sign the tag with the -s option. * git tag -s v<version> -m "Release v<version>"

  3. Push tag to github, on develop

  4. On github, make a PR from develop to stable (this can be done ahead of time and left open, until all individual PRs are merged into develop.).

  5. After verifying that PR is complete and tests pass, merge it. (Once merged, both the stable and develop branches should match).

  6. Release on Github:

    1. On Github, click on “[N] Releases”.

    2. Select “Draft a new release”.

    3. Specify the version number, title, and brief description of the release.

    4. Press “Publish Release”.

  7. Release to PyPI. This should now happen automatically on GitHub Actions. This will be triggered by a GitHub Actions build of a tagged commit on the stable branch, so it will happen automatically on the prior step for the PR into stable.


Once conda installation is working again, find this page in the documentation for version 1.0.0 and adapt the steps from the “Releasing a new version through AstroConda” section to the new process.

Releasing a new version through AstroConda

To test that an Astroconda package builds, you will need conda-build:

$ conda install conda-build
  1. Fork (if needed) and clone

  2. If there is a new version of POPPY available to package, edit poppy/meta.yaml to reflect the new version and git_tag.

  3. If the minimum needed version of the webbpsf-data package has changed in webbpsf/, edit webbpsf-data/meta.yaml to reflect the new version and url.

  4. Edit webbpsf/meta.yaml to reflect the new versions of POPPY and webbpsf-data, if necessary.

  5. Edit in the git_tag name from git tag in the PyPI release instructions (v0.X.Y).

  6. Verify that you can build the package from the astroconda-contrib directory: conda build -c webbpsf

  7. Commit your changes to a new branch and push to GitHub.

  8. Create a pull request against astroconda/astroconda-contrib.

  9. Wait for SSB to build the conda packages.

  10. (optional) Create a new conda environment to test the package installation following these instructions.

Finishing the release

  1. Email an announcement to