diff --git a/docs/wiki/dev-guides/Local-Development-Setup.md b/docs/wiki/dev-guides/Local-Development-Setup.md index 15de91ccf..5dae1abbe 100644 --- a/docs/wiki/dev-guides/Local-Development-Setup.md +++ b/docs/wiki/dev-guides/Local-Development-Setup.md @@ -6,7 +6,6 @@ - [Create your fork](#create-your-fork) - [Configure remotes](#configure-remotes) - [Authenticating with GitHub](#authenticating-with-github) - - [Configure commit signing](#configure-commit-signing) - [Guidelines](#guidelines) ## Step 1: Build CSP from Source @@ -31,19 +30,7 @@ already set that way and click "Create fork". ### Configure remotes Next, you should set some names for the `git` remotes corresponding to -main Point72 repository and your fork. If you started with a clone of -the main `Point72` repository, you could do something like: - -```bash -cd csp -git remote rename origin upstream - -# for SSH authentication -git remote add origin git@github.com:/csp.git - -# for HTTP authentication -git remote add origin https://github.com//csp.git -``` +main Point72 repository and your fork. See the [GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-repository-for-a-fork) for more information. ### Authenticating with GitHub @@ -59,25 +46,6 @@ or adding a [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) to avoid the need to type in your password every time you push to your fork. -### Configure commit signing - -Additionally, you will need to configure your local `git` setup and -GitHub account to use [commit -signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification). All -commits to the `csp` repository must be signed to increase the -difficulty of a supply-chain attack against the CSP codebase. The -easiest way to do this is to [configure `git` to sign commits with your -SSH -key](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification). You -can also use a [GPG -key](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#gpg-commit-signature-verification) -to sign commits. - -In either case, you must also add your public key to your github account -as a signing key. Note that if you have already added an SSH key as an -authentication key, you will need to add it again [as a signing -key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account). - ## Guidelines After developing a change locally, ensure that both [lints](Build-CSP-from-Source#lint-and-autoformat) and [tests](Build-CSP-from-Source#testing) pass. Commits should be squashed into logical units, and all commits must be signed (e.g. with the `-s` git flag). CSP requires [Developer Certificate of Origin](https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin) for all contributions. diff --git a/docs/wiki/dev-guides/Release-Process.md b/docs/wiki/dev-guides/Release-Process.md index 3d417d0c6..b3175dd97 100644 --- a/docs/wiki/dev-guides/Release-Process.md +++ b/docs/wiki/dev-guides/Release-Process.md @@ -10,6 +10,7 @@ - [Download release artifacts from github actions](#download-release-artifacts-from-github-actions) - [Optionally upload to testpypi to test "pip install"](#optionally-upload-to-testpypi-to-test-pip-install) - [Upload to pypi](#upload-to-pypi) + - [Releasing to conda-forge](#releasing-to-conda-forge) - [Dealing with release mistakes](#dealing-with-release-mistakes) ## Doing a "normal" release @@ -74,12 +75,10 @@ Follow these steps when it's time to tag a new release. Before doing this, you will need to ensure `bump2version` is installed into your development environment. -> \[!NOTE\] -> The following steps assume you have a personal fork of csp. -> If you are working from the main `Point72/csp` repo, use `origin` -> instead of `upstream` in the git commands. Specifically, -> `git pull origin main --tags` in the step 1, -> and `git push origin main --follow-tags` in step 7. +> The following steps assume you are pushing to the main `Point72/csp` +> repo. If you are working from a personal fork, use the corresponding +> remote (e.g. `upstream`) instead of `origin` in all git commands. +> Ensure tags are still pushed to `Point72/csp` directly. 1. Ensure your local clone of `csp` is synced up with GitHub, including any tags that have been pushed since you last synced: @@ -99,8 +98,8 @@ development environment. git checkout -b release/v0.x.x ``` - For example, for a bugfix release, `bump2version` will automatically - update the codebase to use the next bugfix version number if you do: + You can update the version number in the codebase using `bump2version`. For a + bugfix release, you would do: ```bash make patch @@ -108,7 +107,8 @@ development environment. Similarly, `make minor` and `make major` will update the version numbers for minor and major releases, respectively. Double-check - that the version numbers have been updated correctly with `git diff`, and then `git commit -s` the change. + that the version numbers have been updated correctly with + `git diff`, and then `git commit -s` the change. 1. Push your branch to GitHub, and trigger a "full" test run on the branch. @@ -118,7 +118,8 @@ development environment. button is selected, and click the green "Run workflow" button to launch the test run. -1. Propose a pull request from the branch containing the version number updated. Add a link to the successful full test run for reviewers. +1. Propose a pull request from the branch containing the version number updated. + Add a link to the successful full test run for reviewers. 1. Review and merge the pull request. Make sure you delete the branch afterwards. @@ -132,10 +133,10 @@ development environment. git tag v0.2.0 ``` -1. Push the tag to GitHub +1. Push the tag to GitHub using the tag name created in the previous step. ```bash - git push upstream main --follow-tags + git push origin tag v0.2.0 ``` You will need access in the repository settings to be able to push @@ -249,6 +250,17 @@ View at: https://pypi.org/project/csp// ``` +### Releasing to conda-forge + +The `conda-forge` release process is largely automated. Maintainers who +are listed under the `extra.recipe-maintainers` field in the `csp` +recipe hosted in [the conda-forge feedstock +repository](https://github.com/conda-forge/csp-feedstock/blob/main/recipe/meta.yaml) +should be automatically subscribed to notifications for the +repository. The [conda-forge maintainer documentation](https://conda-forge.org/docs/maintainer/updating_pkgs/) +has the relevant guidelines and procedures, and should be read thoroughly before +making any changes. + ## Dealing with release mistakes Sometimes releases go wrong. Here is what to do when that happens. This