← ClaudeAtlas

vibey-releasinglisted

The release flow — merge train into develop, vibey-gh promote to main, release.yml publishing (develop to TestPyPI as vibey-dev, main to PyPI), github-release.yml tags, and release-surfaces.yml docs, book and paper. Read before cutting a release.
the-vibey-project/vibey · ★ 2 · AI & Automation · score 71
Install: claude install-skill the-vibey-project/vibey
# vibey releasing `vibey-gh` owns the release (ADR-0028). There is no release-please step and no hand-run publish. The version is *derived*, not chosen: `vibey-gh version` reads what changed against `[version] content_paths` and `code_paths` in `.vibey-gh.toml` and answers minor, patch, or nothing. `vibey-gh promote` applies that answer. The changelog entry is written by hand. Every workflow on the release path installs the tree's own `vibey-gh` from the declared `[install] self_source = "src/vibey_tools/gh"`, and falls back to `vibey-gh==1.73.0` from PyPI only when that path does not hold a `vibey-gh` package. A change to `vibey-gh` therefore changes the release path on the next push. ## Where a release goes PyPI is not the finish line. These are command-line applications, and someone installing a CLI reaches for `brew install` or `winget install` -- that it is written in Python is an implementation detail they should not have to care about. Publish to every registry that can carry it, and treat the channel as part of shipping rather than a follow-up. Every packaging definition -- formula, PKGBUILD, snapcraft.yaml, nuspec, winget manifest -- is to live in this repository and be published by automation, never hand-edited in a tap (ADR-0018, ADR-0019, sub-doctrine 2.b). A stale formula is worse than no formula: it installs an old version silently. **As of 2026-09-15 none of those packaging definitions exist yet.** The channels this repository publishes today are: - PyPI