fix: install in place instead of accumulating versioned kegs#47
Merged
fabianburth merged 2 commits intoJun 10, 2026
Merged
Conversation
The unversioned formula was stuck at v0.18.0 because the release pipeline only ever updated the versioned ocm@<version>.rb files. Sync it to the current release so brew install of the canonical name resolves to a non-stale formula. Signed-off-by: Fabian Burth <fabian.burth@sap.com>
The alias pointed at a versioned formula (ocm@0.43.0.rb), so brew install resolved the canonical name to a versioned formula. Versioned formulas are treated as separate packages by Homebrew and install side-by-side instead of upgrading in place, which caused users to accumulate a new keg per release. With the alias gone, brew install resolves to Formula/ocm.rb (the canonical, unversioned formula), and brew upgrade replaces it in place. Signed-off-by: Fabian Burth <fabian.burth@sap.com>
morri-son
approved these changes
Jun 10, 2026
fabianburth
added a commit
to open-component-model/open-component-model
that referenced
this pull request
Jun 10, 2026
## Summary Add a callout to the legacy install docs explaining the one-time migration step for users who installed the OCM CLI via Homebrew before the tap was fixed. Background: earlier tap releases installed the CLI as a version-pinned formula (e.g. \`ocm@0.43.0\`), so brew treated each release as a separate package and accumulated side-by-side kegs instead of upgrading in place. The tap is now fixed to use the canonical \`Formula/ocm.rb\` (open-component-model/homebrew-tap#47, with the release pipeline change in open-component-model/ocm#1997), but existing users stay stuck on their pinned version until they manually uninstall it and reinstall the canonical formula. ## Test plan - [x] Render the legacy install docs and verify the callout displays correctly. - [x] Reviewer sanity-checks the wording. --------- Signed-off-by: Fabian Burth <fabian.burth@sap.com>
fabianburth
added a commit
to open-component-model/ocm
that referenced
this pull request
Jun 10, 2026
…1997) ## 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>
ocmbot Bot
pushed a commit
to open-component-model/open-component-model
that referenced
this pull request
Jun 10, 2026
## Summary Add a callout to the legacy install docs explaining the one-time migration step for users who installed the OCM CLI via Homebrew before the tap was fixed. Background: earlier tap releases installed the CLI as a version-pinned formula (e.g. \`ocm@0.43.0\`), so brew treated each release as a separate package and accumulated side-by-side kegs instead of upgrading in place. The tap is now fixed to use the canonical \`Formula/ocm.rb\` (open-component-model/homebrew-tap#47, with the release pipeline change in open-component-model/ocm#1997), but existing users stay stuck on their pinned version until they manually uninstall it and reinstall the canonical formula. ## Test plan - [x] Render the legacy install docs and verify the callout displays correctly. - [x] Reviewer sanity-checks the wording. --------- Signed-off-by: Fabian Burth <fabian.burth@sap.com> 18bfd88
matthiasbruns
pushed a commit
to knp-sap/ocm
that referenced
this pull request
Jun 15, 2026
…pen-component-model#1997) ## 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> Signed-off-by: Matthias Bruns <git@matthiasbruns.com>
sk31337
pushed a commit
to sk31337/open-component-model
that referenced
this pull request
Jun 19, 2026
…n-component-model#2802) ## Summary Add a callout to the legacy install docs explaining the one-time migration step for users who installed the OCM CLI via Homebrew before the tap was fixed. Background: earlier tap releases installed the CLI as a version-pinned formula (e.g. \`ocm@0.43.0\`), so brew treated each release as a separate package and accumulated side-by-side kegs instead of upgrading in place. The tap is now fixed to use the canonical \`Formula/ocm.rb\` (open-component-model/homebrew-tap#47, with the release pipeline change in open-component-model/ocm#1997), but existing users stay stuck on their pinned version until they manually uninstall it and reinstall the canonical formula. ## Test plan - [x] Render the legacy install docs and verify the callout displays correctly. - [x] Reviewer sanity-checks the wording. --------- Signed-off-by: Fabian Burth <fabian.burth@sap.com> Signed-off-by: sk31337 <sk31337@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
brew installof this tap currently installs each release as a side-by-side keg instead of upgrading in place, so users pile upocm@0.18.0,ocm@0.40.0, …,ocm@0.43.0over time.Two issues, two commits:
Formula/ocm.rbwas stale at v0.18.0. The release pipeline only ever updated the versionedocm@<version>.rbfiles. Bump it to v0.43.0 to match the latest release.Aliases/ocmshadowedFormula/ocm.rband pointed at the latest versioned formula. Brew aliases take precedence over same-named formula files, sobrew install …/ocmresolved toocm@0.43.0(a versioned formula). Homebrew treats versioned formulas as separate packages, hence the pile-up. Remove the alias so the canonicalFormula/ocm.rbis what resolves.The companion change in
open-component-model/ocmupdates the release pipeline to keepFormula/ocm.rbin sync going forward and stop creating the alias: open-component-model/ocm#1997Migration
Existing users on the alias path stay on
ocm@0.43.0because brew sees that formula still exists in the tap and there's noocmkeg to upgrade. One-time migration:WE NEED TO FLAG THIS IN THE RELEASE NOTES AND ON THE WEBSITE!
Also, this is a pre-requisite for the updated release flow to work. So it needs to be merged before the next ocm release.
Test plan
brew info …/ocmresolves to canonicalname: "ocm",aliases: [], stable 0.43.0.brew info …/ocm@0.43.0still resolves to the versioned formula (opt-in pin still works).