You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Summary
Users who install via `brew install open-component-model/tap/ocm`
accumulate a new keg per release (`ocm@0.40.0`, `ocm@0.41.0`, …) instead
of upgrading in place. Root cause is in this repo's release pipeline.
The publish workflow only ever generated `Formula/ocm@<version>.rb` and
pointed `Aliases/ocm` at the latest one. Brew aliases shadow same-named
formula files and resolve to the target, so `brew install …/ocm`
installed a versioned formula. Homebrew treats versioned formulas as
separate packages and installs them side-by-side, hence the pile-up.
Generate **both** files on every release:
- `Formula/ocm.rb` (class `Ocm`) — canonical, overwritten each release;
`brew install ocm` upgrades in place.
- `Formula/ocm@<version>.rb` (class `OcmAT<digits>`) — opt-in pin; users
who want a specific version run `brew install ocm@X.Y.Z`.
Drop the `Aliases/ocm` symlink creation in the workflow and remove any
stale symlink left over from earlier runs.
Companion cleanup in the tap (bumps `Formula/ocm.rb` to v0.43.0 manually
so users aren't stuck on v0.18.0 until the next release, and removes the
existing `Aliases/ocm`):
open-component-model/homebrew-tap#47
## Test plan
- [x] `go test ./...` in `hack/brew` passes
- [x] Generator output for v0.43.0 byte-identical to the existing tap
files (both `Formula/ocm.rb` and `Formula/ocm@0.43.0.rb`)
- [x] Locally tapped a synthetic tap with both generated files: `brew
info …/ocm` resolves to canonical formula 0.43.0; `brew info
…/ocm@0.43.0` still resolves to the versioned formula
- [x] Reviewer sanity-checks the workflow diff
---------
Signed-off-by: Fabian Burth <fabian.burth@sap.com>
0 commit comments