Skip to content

Remove completed initial release steps #17

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
yarikoptic merged 1 commit into from
Jun 2, 2026
Merged

Remove completed initial release steps #17

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
99 changes: 1 addition & 98 deletions RELEASING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
<https://pypi.org/manage/account/token/> (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: <the project-scoped pypi token from Step 2>

# 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
Expand Down
Loading