These are internal notes for PyFstat maintainers, especially about preparing releases.

Currently, a full release should update the following:

• local release tag: https://github.com/PyFstat/PyFstat/releases
• local Docker builds: https://github.com/orgs/PyFstat/packages?repo_name=PyFstat
• Zenodo: https://doi.org/10.5281/zenodo.3967045
• PyPi: https://pypi.org/project/PyFstat/
• Conda forge: https://anaconda.org/conda-forge/pyfstat
• ReadTheDocs documentation: https://pyfstat.readthedocs.io/en/stable/

1. Check if the integration tests currently pass, and ideally also manually run the slower "Run examples" action by hand from here.
2. Check if the last release has processed fully - in particular, for conda forge we should not start a new release from the github side before their bot has processed the last one, otherwise it will apparently skip it.
3. Decide on a new version name. The scheme is vx.y.z where x=1 until further notice (i.e. until any very significant core rewrite), y gets incremented for any significant new features or backwards-incompatible API changes, and z gets incremented for any other small changes (bug fixes, minor additions, changes only to documentation or examples, etc).
4. Update the changelog on master -- TODO: check https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes
5. The standard release procedure, for simplicity, currently works directly off master. If however a bugfix release vx.y.z+1 to the latest stable release vx.y.z is needed while master development has already progressed to a backwards-incompatible point that would require a vx.y+1.z release, but is not ready for that one yet, then a bugfix release should be made off a separate release branch. Fork this after updating the changelog for vx.y.z+1 on master, then merge in or cherry-pick the required bugfix commits.
6. Go to https://github.com/PyFstat/PyFstat/releases , copy the text from the last release notes as a template, and click on "Draft a new release".
7. Update the "tag version" and "Release title" fields to the same vx.y.z number and paste the detailed description, updating in it the version number, date and changelog excerpt. Click on "Publish release".
8. Go through the list of release channels that need to be updated; most are automated or at least semi-automated. See details below.

• Fully automatic.
• Check the status of the auto-build action.
• It's configured from this .yml.
• Also see the Containers page.

• This should update automatically, usually within seconds. If it doesn't, check here for failures and, if we can't fix it from our side, report it here.

• Mostly automatic.
• Packages are uploaded at the end of the main "Integration Tests" action whenever a release (=tag) is created. The action is configured from this .yml. It tries to upload to test.pypi.org first and to the main instance only if that one worked.
• As of 2024, for the real PyPI there is now a "Deployment review" step where an email is sent and an approval button has to be clicked before the upload happens.

• An automated bot watches for PyPi releases and then creates a PR on https://github.com/conda-forge/pyfstat-feedstock/pulls . This can take a while, see here, and will not generate additional PRs if there are two releases within a short window (hence, avoid those!).
• The bot's checkboxes should be followed before merging; in particular, LALSuite dependencies need to be manually updated if they have changed, as conda uses separate packages for the different modules of the suite while our own requirements.txt and setup.py refer to a global LALSuite version number. To get the right numbers, you may need to dig through LALSuite's history, or:
  1. install the new PyPi package into a local venv
  2. inside python, check import lalpulsar, lalpulsar.__version__
  3. outside python, check lalapps_version
• For release candidates, a more manual procedure is needed, see this documentation. NOTE that when they say "Used a personal fork of the feedstock to propose changes" they actually mean "personal" as in "single-user", because "PRs from organization accounts cannot be rerendered because of GitHub permissions", so the first step is to fork into the maintainer's own namespace (not into pyfstat), create a branch with the updated recipe there, and then a PR into the official feedstock repo's rc branch.

• The stable channel will automatically update (check build status here).
• Permanent version-specific vx.y.z builds should also usually be created automatically, but if one must be triggered manually, this can be done through the dropdown and "Build Version" button on that same page.
• Errors of the type Unable to locate build via Github Actions API. Please upload with the Codecov repository upload token to resolve issue. seem to be just a weird expression of a timeout error / rate limitation, see https://github.com/codecov/codecov-action/issues/557
• OS and python versions may need to be updated once in a while in https://github.com/PyFstat/PyFstat/blob/master/.readthedocs.yml

• After updating integration.yml (or in principle other workflows run by actions on each PR and required to pass), it can happen that jobs that were removed still show up but never run, e.g. build (3.x) Expected — Waiting for status to be reported after removing python 3.x from the matrix. To fix this, go to "settings/branch_protection_rules" and update "Status checks that are required".