11# Release Process
22
3- This project follows the same broad release model as UXarray:
3+ This project follows the same broad release model as UXarray, with an added
4+ scheduled release workflow:
45
561 . GitHub CI must be green on ` main ` .
6- 2 . A GitHub Release is published from a ` v<version> ` tag.
7- 3 . The release workflow builds and publishes the Python package to PyPI.
8- 4 . Conda packages are handled through a conda-forge feedstock.
7+ 2 . On the 5th of every month, GitHub Actions checks for commits since the
8+ latest ` v* ` tag.
9+ 3 . If there are no new commits, the release is skipped.
10+ 4 . If there are new commits, the workflow bumps the patch version, commits it,
11+ creates a ` v<version> ` tag, and publishes a GitHub Release.
12+ 5 . The release workflow builds and publishes the Python package to PyPI.
13+ 6 . Conda packages are handled through a conda-forge feedstock.
14+
15+ ## Monthly Automation
16+
17+ ` .github/workflows/monthly-release.yml ` runs at 05:00 UTC on the 5th of every
18+ month. It can also be run manually with ` workflow_dispatch ` .
19+
20+ Default behavior:
21+
22+ - no previous ` v* ` tag: release the current version from ` pyproject.toml `
23+ - previous ` vX.Y.Z ` tag exists and commits have landed since then: release
24+ ` X.Y.(Z+1) `
25+ - no commits since the latest tag: skip
26+
27+ Manual inputs:
28+
29+ - ` version ` : release an explicit version such as ` 0.1.0 `
30+ - ` force ` : release even if there are no commits since the latest tag
31+
32+ The workflow updates:
33+
34+ - ` pyproject.toml `
35+ - ` src/uxarray_mcp/__init__.py `
36+ - ` conda/recipe/meta.yaml `
37+
38+ Then it runs the release checks, builds the package, commits the version bump,
39+ tags it, pushes to ` main ` , and creates the GitHub Release.
940
1041## PyPI
1142
@@ -19,6 +50,9 @@ Before the first release, configure PyPI trusted publishing:
1950- Workflow: ` release.yml `
2051- Environment: ` pypi `
2152
53+ The GitHub repository must also have an environment named ` pypi ` and Actions
54+ workflow permissions set to read/write.
55+
2256Release steps:
2357
2458``` bash
@@ -29,8 +63,8 @@ uv run --extra docs sphinx-build -b html docs docs/_build/html -W --keep-going
2963uv build
3064```
3165
32- Then create and publish a GitHub Release for a tag such as ` v0.1.0 ` . The
33- workflow will:
66+ The release workflow ( ` .github/workflows/release.yml ` ) runs after a GitHub
67+ Release is published. It will:
3468
3569- build the source distribution and wheel
3670- run ` twine check `
@@ -57,6 +91,21 @@ Conda packages should be published through conda-forge, not from this repository
5791directly. A seed recipe lives at ` conda/recipe/meta.yaml ` to bootstrap a future
5892` uxarray-mcp-feedstock ` .
5993
94+ Fully automatic Conda releases require a feedstock repository and two GitHub
95+ settings in this repository:
96+
97+ - variable ` CONDA_FEEDSTOCK_REPOSITORY ` , for example
98+ ` conda-forge/uxarray-mcp-feedstock `
99+ - secret ` CONDA_FEEDSTOCK_TOKEN ` , a token with permission to push branches and
100+ open pull requests on that feedstock
101+
102+ When those are configured, the PyPI release workflow will update the feedstock
103+ recipe hash/version, open a pull request, and enable auto-merge. Conda-forge CI
104+ then builds and uploads the package after the PR merges.
105+
106+ If those settings are not configured, the workflow still publishes PyPI and
107+ skips the feedstock update with a clear log message.
108+
60109Feedstock steps:
61110
621111 . Publish the PyPI release first.
0 commit comments