Development Cycle

Starting a new release

Create a new integration/X.Y.Z branch off master.
Switch to this branch and update __version_number in sarpy/__about__.py to X.Y.Za0
In Read the Docs, change Admin > Settings > Default branch to integration/X.Y.Z

Create pull requests that target integration/X.Y.Z.
Before merging each pull request, verify that:
- the pre-release segment of __version_number in sarpy/__about__.py is incremented (e.g. X.Y.Za1 etc.)
- CHANGELOG.md is updated as appropriate
Branches merged into integration/X.Y.Z should be squashed.

Assuming you have an integration/X.Y.Z branch off master that is being considered for release:

Create a new release/X.Y.Z branch off integration/X.Y.Z and switch to it.
Merge master into release/X.Y.Z and resolve any conflicts.
Set __version_number in sarpy/__about__.py to X.Y.Z
Update CHANGELOG.md as appropriate (e.g. date in release header)
Run tests.
Submit the release/X.Y.Z branch as a pull request into integration/X.Y.Z taking care to document the unittest results.

Assuming you have an integration/X.Y.Z branch off master that has been prepared for release:

Submit the integration/X.Y.Z branch as a pull request into master taking care to document the unittest and Read the Docs artifacts from testing.
Merge changes back into master without squashing.
Create and push an annotated vX.Y.Z tag onto the resulting commit (this is done from the command line; e.g. git tag -a vX.Y.Z -m "vX.Y.Z" and git push origin tag vX.Y.Z).
Run the pypi.yml GitHub workflow (in the GitHub GUI) from the vX.Y.Z tag. PyPI publishing jobs will wait for an approval before starting.
Check Read the Docs to ensure build was triggered and successful. Set "Admin > Settings > Default branch" back to master.

Assuming you have an release/X.Y.Z branch, perform the following in linux and windows:

Ensure you have the latest nox installed and SARPY_TEST_PATH set appropriately.
Run the tests using nox.