Update CI & release checklist for release branch

.github/ISSUE_TEMPLATE/release-checklist.md

@@ -7,7 +7,7 @@ assignees: ''
 
 ---
 
-**Release**: [v0.x.x](https://github.com/zarr-developers/zarr-python/milestones/?)
+**Release**: [v3.x.x](https://github.com/zarr-developers/zarr-python/milestones/?)
 **Scheduled Date**: 20YY/MM/DD
 
 **Priority PRs/issues to complete prior to release**
@@ -16,8 +16,9 @@ assignees: ''
 
 **Before release**:
 
+- [ ] Make sure the release branch (e.g., `3.1.x`) is up to date with any backports.
 - [ ] Make sure that all pull requests which will be included in the release have been properly documented as changelog files in the [`changes/` directory](https://github.com/zarr-developers/zarr-python/tree/main/changes).
-- [ ] Run ``towncrier build --version x.y.z`` to create the changelog, and commit the result to the main branch.
+- [ ] Run ``towncrier build --version x.y.z`` to create the changelog, and commit the result to the release branch.
 - [ ] Check [SPEC 0](https://scientific-python.org/specs/spec-0000/#support-window) to see if the minimum supported version of Python or NumPy needs bumping.
 - [ ] Check to ensure that:
   - [ ] Deprecated workarounds/codes/tests are removed. Run `grep "# TODO" **/*.py` to find all potential TODOs.
@@ -41,6 +42,7 @@ assignees: ''
 - [ ] Go to https://github.com/zarr-developers/zarr-python/releases.
   - [ ] Click "Draft a new release".
   - [ ] Choose a version number prefixed with a `v` (e.g. `v0.0.0`). For pre-releases, include the appropriate suffix (e.g. `v0.0.0a1` or `v0.0.0rc2`).
+  - [ ] Set the target branch to the release branch (e.g., `3.1.x`)
   - [ ] Set the description of the release to: `See release notes https://zarr.readthedocs.io/en/stable/release-notes.html#release-0-0-0`, replacing the correct version numbers. For pre-release versions, the URL should omit the pre-release suffix, e.g. "a1" or "rc1".
   - [ ] Click on "Generate release notes" to auto-fill the description.
   - [ ] Make a release by clicking the 'Publish Release' button, this will automatically create a tag too.

.github/workflows/gpu_test.yml

@@ -5,9 +5,9 @@ name: GPU Test
 
 on:
   push:
-    branches: [ main ]
+    branches: [ main, 3.1.x ]
   pull_request:
-    branches: [ main ]
+    branches: [ main, 3.1.x ]
   workflow_dispatch:
 
 env:

.github/workflows/hypothesis.yaml

@@ -1,9 +1,9 @@
 name: Slow Hypothesis CI
 on:
   push:
-    branches: [main, 3.0.x]
+    branches: [main, 3.1.x]
   pull_request:
-    branches: [main, 3.0.x]
+    branches: [main, 3.1.x]
     types: [opened, reopened, synchronize, labeled]
   schedule:
     - cron: "0 0 * * *" # Daily “At 00:00” UTC

.github/workflows/test.yml

@@ -5,9 +5,9 @@ name: Test
 
 on:
   push:
-    branches: [ main, 3.0.x ]
+    branches: [ main, 3.1.x ]
   pull_request:
-    branches: [ main, 3.0.x ]
+    branches: [ main, 3.1.x ]
   workflow_dispatch:
 
 concurrency:

docs/developers/contributing.rst

@@ -261,9 +261,12 @@ Pull requests submitted by an external contributor should be reviewed and approv
 one core developer before being merged. Ideally, pull requests submitted by a core developer
 should be reviewed and approved by at least one other core developer before being merged.
 
-Pull requests should not be merged until all CI checks have passed (GitHub Actions
+Pull requests should not be merged until all CI checks have passed (GitHub Actions,
 Codecov) against code that has had the latest main merged in.
 
+Before merging the milestone must be set either to decide whether a PR will be in the next
+patch, minor, or major release. The next section explains which types of changes go in each release.
+
 Compatibility and versioning policies
 -------------------------------------