From 1a0147ca751f4e7bd599a73c2552d7bb82ec75bf Mon Sep 17 00:00:00 2001 From: Yaroslav Halchenko Date: Tue, 2 Jun 2026 08:53:00 -0400 Subject: [PATCH] Remove completed initial release steps --- RELEASING.md | 99 +--------------------------------------------------- 1 file changed, 1 insertion(+), 98 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index 899bccb..c837df8 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -33,104 +33,7 @@ where the bump label was forgotten. --- -## Cutting v0.1.0 (initial release) — full runbook - -The first release is intentionally manual because `auto` needs a baseline -tag (`v0.1.0`) to start counting PR labels from. After 0.1.0 the -label-driven workflow takes over. - -### Step 0 — prerequisites (one-time, on the maintainer's machine) - -```bash -# Ensure local build tooling is available -pip install --upgrade build twine - -# Optional but recommended: install auto so you can dry-run locally -npm install -g auto # or use the binary download path from release.yml - -# Ensure your PyPI account has write access to the bids-utils project, -# OR that you have a project-scoped API token for it -``` - -### Step 1 — merge the release-pipeline branch - -Merge the `enh-auto-release` PR (containing `.autorc`, -`.github/workflows/release.yml`, `CHANGELOG.md`, `RELEASING.md`, -CONTRIBUTING.md updates) into `main`. The first release CANNOT proceed -until this is on `main`, because `release.yml` and the `auto` config are -what wire everything together. - -### Step 2 — create repo labels and the PyPI token (one-time, on GitHub side) - -```bash -# Create the auto release labels (major, minor, patch, release, ...) -GH_TOKEN=$(git config hub.oauthtoken) intuit-auto create-labels -``` - -Then on the GitHub web UI: - -1. Generate a project-scoped API token at - (scoped to `bids-utils`). -2. Add it as repo secret `PYPI_TOKEN` under - *Settings → Secrets and variables → Actions*. - -If you prefer OIDC-based publishing without a long-lived token, see -"Optional: PyPI Trusted Publishing" below — equivalent end-state, just a -different setup. - -### Step 3 — cut the tag and publish - -```bash -# 1. Make sure you're on main and clean -git checkout main -git pull --ff-only -git status # must be clean - -# 2. Run the full local test suite as a final gate -tox - -# 3. Sanity-check what hatch-vcs will produce AT the tag -# (without the tag, this shows a 0.1.devNN+gSHA dev version) -python -m build -ls dist/ -rm -rf dist/ # discard the dev-version artifacts; we'll rebuild at the tag - -# 4. Tag v0.1.0 and push the tag -git tag -a v0.1.0 -m "v0.1.0" -git push origin v0.1.0 - -# 5. Build the release artifacts from the tagged commit -python -m build -ls dist/ -# Expect: bids_utils-0.1.0-py3-none-any.whl AND bids_utils-0.1.0.tar.gz - -# 6. (Optional but recommended) twine check before upload -twine check dist/* - -# 7. Upload to PyPI -twine upload dist/* -# When prompted: -# Username: __token__ -# Password: - -# 8. Create the GitHub release with the CHANGELOG entry as the body -gh release create v0.1.0 --title "v0.1.0" \ - --notes "$(awk '/^# v0\.1\.0/,/^---$/' CHANGELOG.md | sed '$d')" -``` - -### Step 4 — sanity-check the release - -```bash -# Verify the artifact is up on PyPI -pip index versions bids-utils - -# Verify a fresh install works -python -m venv /tmp/bids-utils-smoke && \ - /tmp/bids-utils-smoke/bin/pip install bids-utils==0.1.0 && \ - /tmp/bids-utils-smoke/bin/bids-utils --help -``` - -### Step 5 — confirm the release.yml workflow is healthy +### Step 5 (TODO) — confirm the release.yml workflow is healthy After v0.1.0 is tagged, the next merge to `main` will trigger `release.yml`. If that merged PR has no `release` label, the workflow