koopa-release

النجوم١١

التفرعات١

آخر تحديث١٩ يونيو ٢٠٢٦ في ١٥:٤٠

koopa release procedure — CHANGELOG authoring, bumpver contract, pre-release gate, and what stays with the user. Use when preparing a release, writing release notes, or understanding what "prepare the release" entails.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

المصدر

acidgenomics

acidgenomics/koopa

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

SKILL.md

readonly

name	koopa-release
description	koopa release procedure — CHANGELOG authoring, bumpver contract, pre-release gate, and what stays with the user. Use when preparing a release, writing release notes, or understanding what "prepare the release" entails.

koopa Release Procedure

What bumpver does (and doesn't do)

bumpver is configured in pyproject.toml with tag = false, push = false, commit = true. Running bumpver update (or equivalent) bumps two lines in pyproject.toml:

version = "<pep440>" (no v prefix)
current_version = "v<version>" (with v prefix)

It creates a single commit Bump version to vX.Y.Z. — no tag, no push. Tagging, pushing, and merging develop→main are always the user's job.

Release checklist

Version bump — already done by bumpver (the Bump version to vX.Y.Z. commit). Confirm pyproject.toml:3 reads the new version.
Write CHANGELOG.md — prepend a new section directly above the previous ## koopa X.Y.Z (...) heading. See format below.

Pre-release gate — all must pass:

pytest lang/python/tests/
ruff check lang/python/src/
ruff format --check lang/python/src/
pyright lang/python/src/

User-owned — git tag vX.Y.Z, git push origin develop, git push origin vX.Y.Z, merge develop→main via PR.

CHANGELOG.md format

File: CHANGELOG.md at the repo root.

Section heading: ## koopa X.Y.Z (YYYY-MM-DD)

Bare version — no v prefix.
ISO date in parentheses — use the date of the version-bump commit.
No blank line between ## heading and the first subsection heading.

Subsections (in order, omit if empty):

Major changes: — substantive user-facing changes, ~4-6 bullets.
Minor changes: — small fixes, housekeeping, version bumps.
New apps: — only present when new top-level keys were added to etc/koopa/app.json this cycle. Verify with: git diff vPREV..HEAD -- etc/koopa/app.json | grep -E '^\+ "[a-z]'

Bullet style: - list, wrapped at ~80 columns, two-space continuation indent. Match the style of the surrounding entries exactly.

Determining the commit range

Previous release tag: find the prior Bump version to vX.Y.Z. commit or the existing vPREV git tag. The range is vPREV..HEAD (or PREV_BUMP_SHA..HEAD if the tag hasn't been created yet for the previous release).

What to include / exclude

Include: license changes, new modules, new CLI commands, new apps, significant shell/config parity work, performance fixes, version-check improvements.
Exclude: Claude config/skills/rules reorganizations (internal tooling), todo updates, merge commits, Prepare release housekeeping commits.
New apps: entries: name, version, one-line description, default/non-default.

Version source of truth

pyproject.toml:3 — version = "X.Y.Z". Read at runtime by koopa_version() in lang/python/src/koopa/version.py. No other file hardcodes the koopa version.

المزيد من هذا المستودع

نفس المستودع

acid-r-package

acidgenomics/koopa

Acid Genomics R package development conventions — per-project air.toml, global ~/.lintr only, roxygen2 8.x @importFrom split, S4 linter tuning, AcidDevTools::check() gate. Use when writing or checking an acidgenomics R package, configuring air/lintr, or fixing roxygen/lint failures.

2026-07-2711

koopa-r-release

acidgenomics/koopa

koopa R package release — cloud-native S3 + CloudFront, acidgenomics profile, koopa app r publish/reindex/archive, sonoma-arm64 binaries, pre-release AcidDevTools::check() gate. Use when releasing, publishing, reindexing, or archiving an Acid Genomics R package.

2026-07-2711

powershell

acidgenomics/koopa

PowerShell (pwsh 7+) activation architecture, starship integration, and color-mode sync in koopa. Use when writing or debugging lang/powershell/ files, editing activate-*.ps1 functions, adding prompt-tool support (starship, zoxide), integrating OS appearance detection, or porting shell logic from bash/zsh/fish to PowerShell.

2026-07-2511

koopa-aws-env

acidgenomics/koopa

koopa AWS environment configuration — the gitignored <koopa-root>/.env, load_dotenv()/aws_account_id()/koopa_s3_bucket() helpers in aws.py, required vars, bucket naming, lazy-eval rule. Use when adding an AWS secret, wiring a bucket/CloudFront ID, or debugging a missing AWS env var in release tooling.

2026-07-2511

koopa-chezmoi-dotfiles

acidgenomics/koopa

How koopa manages home dotfiles via chezmoi — source-of-truth layout, the explicit --source flag, template-vs-generator ordering, XDG path derivation in templates, symlink_ source files for App Support bridges, diagnosing chezmoi status contamination from stale env, and the correct re-run command. Use when editing a dotfile, working in opt/dotfiles/chezmoi/, debugging a file that reverts on chezmoi apply, wiring a chezmoi template, or bridging XDG paths to macOS Library/Application Support.

2026-07-2511

koopa-color-mode

acidgenomics/koopa

How koopa propagates and applies dark/light color mode across SSH, tmux, shells, and chezmoi-rendered theme files. Use when debugging wrong-palette or stale-theme symptoms after a dark↔light flip, working on color-mode sync jobs or watchers, editing the chezmoi color-mode apply path, or investigating why bat/starship/delta renders the wrong theme while fzf/LS_COLORS look correct.

2026-07-2511

name	koopa-release
description	koopa release procedure — CHANGELOG authoring, bumpver contract, pre-release gate, and what stays with the user. Use when preparing a release, writing release notes, or understanding what "prepare the release" entails.

koopa Release Procedure

What bumpver does (and doesn't do)

bumpver is configured in pyproject.toml with tag = false, push = false, commit = true. Running bumpver update (or equivalent) bumps two lines in pyproject.toml:

version = "<pep440>" (no v prefix)
current_version = "v<version>" (with v prefix)

It creates a single commit Bump version to vX.Y.Z. — no tag, no push. Tagging, pushing, and merging develop→main are always the user's job.

Release checklist

Version bump — already done by bumpver (the Bump version to vX.Y.Z. commit). Confirm pyproject.toml:3 reads the new version.
Write CHANGELOG.md — prepend a new section directly above the previous ## koopa X.Y.Z (...) heading. See format below.

Pre-release gate — all must pass:

pytest lang/python/tests/
ruff check lang/python/src/
ruff format --check lang/python/src/
pyright lang/python/src/

User-owned — git tag vX.Y.Z, git push origin develop, git push origin vX.Y.Z, merge develop→main via PR.

CHANGELOG.md format

File: CHANGELOG.md at the repo root.

Section heading: ## koopa X.Y.Z (YYYY-MM-DD)

Bare version — no v prefix.
ISO date in parentheses — use the date of the version-bump commit.
No blank line between ## heading and the first subsection heading.

Subsections (in order, omit if empty):

Major changes: — substantive user-facing changes, ~4-6 bullets.
Minor changes: — small fixes, housekeeping, version bumps.
New apps: — only present when new top-level keys were added to etc/koopa/app.json this cycle. Verify with: git diff vPREV..HEAD -- etc/koopa/app.json | grep -E '^\+ "[a-z]'

Bullet style: - list, wrapped at ~80 columns, two-space continuation indent. Match the style of the surrounding entries exactly.

Determining the commit range

What to include / exclude

Include: license changes, new modules, new CLI commands, new apps, significant shell/config parity work, performance fixes, version-check improvements.
Exclude: Claude config/skills/rules reorganizations (internal tooling), todo updates, merge commits, Prepare release housekeeping commits.
New apps: entries: name, version, one-line description, default/non-default.

Version source of truth

pyproject.toml:3 — version = "X.Y.Z". Read at runtime by koopa_version() in lang/python/src/koopa/version.py. No other file hardcodes the koopa version.