Stpsf

. ``$ git push upstream <release-tag>``
. Go to stable branch, and look at where it says how many commits behind it is from develop. Click that to generate a pull request (do not squash when you merge here)
. When tests pass merge them to stable
. Release on Github:
. On Github, click on ``[N] Releases``
. Select ``Draft a new release``.
. Specify the version number, title, and brief description of the release.
. Press ``Publish Release``
. Release to PyPI should now happen automatically on GitHub Actions. This will be triggered by a GitHub Actions build of a tagged commit on the `stable` branch.
. Verify that files stored in ``/grp/stpsf/stpsf-data`` (symlink directory) have the correct permissions.
. ``$ cd /grp/stpsf/``
. ``$ find . -type f -exec chmod 755 {} \;`` (current and all subdirectories should be rwxr-xr-x)
. Email an announcement to ``stpsf-usersmaillist.stsci.edu``

. Auto-generate the release notes
. Copy output to ``docs/relnotes.rst``
. Verify everything on sphinx locally on your computer (in docs directory $make html)
. make sure sphinx is installed properly with its needed dependencies
. navigate to docs folder
. ``$ pip install -r requirements.txt``
. ``$ pip uninstall graphviz``
. ``$ conda install graphviz``
. ``$ make clean`` (not needed for initial run, just to reset everything)
. ``$ make html``
. Merge in any changes you've made including release notes
* NOTE: If the builds fail, this may be because we dont have the data cache fetched yet if so:
. Go to https://github.com/spacetelescope/stpsf/actions/workflows/download_data.yml
. Open "Run Workflow" box, change it to point to your pre-release-xxx branch (or whatever your pre release branch is named), run it
. It should then make a cache for you of the new version data
. If you look at https://github.com/spacetelescope/stpsf/actions/caches, you will see what is available that the CI can pick from
. THIS may still not solve the problem, as the cache is only in your branch, not the actual PR. so if the branch passes, the PR should
. Theoretically be fine (despite its failure). You can merge, and then re-run the "dowload data" action for develop, and then re-run your failed jobs in develop.
. Do not release unless develop is passing all tests
. Update the test_readthedocs branch. Force development there. Test it on readthedocs (it should be hidden on the actual site).
. Checkout the branch you want to overwrite (test_readthedocs) ``$git checkout test_readthedocs``
. Reset the target branch to match the source branch (develop) ``$git reset --hard develop``
. Push to the github repo (probably upstream, may be origin, just dont do your personal one) ``$git push upstream test_readthedocs --force``
. Once readthe docs looks all good test your release on test pypi.
. Create new env and install STPSF
. ``$ pip install build twine``
. ``$ python -m build``
. ``$ twine check dist/*``
. ``$ twine upload --repository-url https://test.pypi.org/legacy/ dist/* --verbose`` (NOTE: API token is the password in your ~/.pypirc testpypi token)
. test that you can download and install in fresh env (have pypi as backup for libraries that aren't on testpypi):
. ``$ pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ stpsf==<VERSION>``
. Tag a version in develop and push it to git (do it through local terminal, not through website)