vibey-releasinglisted
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