Consider moving into Homebrew GitHub organisation

[MikeMcQuaid]

• [x] None of the templates was appropriate for my issue, or I’m not sure.

I think the Homebrew/brew merge of brew cask code has been a massive success. I'd like to propose that you consider moving caskroom/homebrew-cask into Homebrew/homebrew-cask. I think this would help unify the projects and communities a little bit more and generally strengthen both projects.

I think it would be cool to also consider moving the other taps over, too. The only problem is a naming collision with caskroom/homebrew-versions and Homebrew/homebrew-versions but I'd also propose considering the addition of the versioned casks into caskroom/homebrew-cask (this would also be consistent with homebrew/homebrew-core).

Thoughts? Concerns? Feelings?

[joshka]

On the versions part of this (and this may be something to cut off into another issue - please suggest we do so if this thread is not the right place for this). A particular use case that I'd like to be able to solve easily came up the other day in conversation. A music producer friend had an old track that he wrote using a specific version of a VST (a synthesizer) which he couldn't find again. It would have been nice to be able to say brew cask install some-synth@1.2.3 as the right solution for this.

[vitorgalvao]

@joshka We’re talking about a change in nomenclature, meaning the rules on what old versions to actually include are not likely to change that much. I’d be surprised if in the case of your friend there were even two people in the exact same situation. Keeping multiple versions of plugins is not something we’ll aim for.

[joshka]

It’s exceedingly common with both music software and development software able to run specific point versions of software for compatability reasons. I’m not suggesting that the policy of the main tap changes, more getting an understanding of how to implement this in my own taps where I want the policy to be different.

[mwean]

Yeah I agree. I've had to switch away from homebrew for many of my development dependencies (e.g. postgresql) because I need precise control of versions.

[MikeMcQuaid]

It’s exceedingly common with both music software and development software able to run specific point versions of software for compatability reasons.

For "compatibility reasons" also read "to increase the change of having your machine owned by widely known, already patched security vulnerabilities (particularly on networked software)".

I’m not suggesting that the policy of the main tap changes, more getting an understanding of how to implement this in my own taps where I want the policy to be different.

The same way you handle it on any formula/cask/tap: copy the file you want at the version you want to your own tap and then maintain it there yourself.

I've had to switch away from homebrew for many of my development dependencies (e.g. postgresql)

This is entirely off-topic to this conversation that's not about Homebrew.

[claui]

getting an understanding of how to implement this in my own taps where I want the policy to be different.

@joshka I recommend to do that as suggested in How to Create and Maintain a Tap. It’s an excellent one-pager, and applies for casks as well as formulas.

[joshka]

@claui I created https://github.com/joshka/homebrew-audio last night as a response to and issue of putting all the VSTs that a manufacturer makes into homebrew-cask would blow out the count of casks in the core repo for little upside. In there there are a few examples of this problem on a v1 to v2 cask as well as many examples where I explicitly included every version of every plugin available from d16 in the git history (I scripted the repo creation, I’m not insane). This means a person who needs 1.0.0 when 1.1.0 is out installs from a github link, while a person requiring the latest v1 uses brew cask install foo, and a v2 user does brew cask install foo2. 3 ways to install depending on the version.

When I’m near a computer I’ll raise a seperate issue to track this instead of continuing in this thread.

Mike, In the case of software upgrades, another thing that explicitly changes is that software versions may be paid upgrades. Just because a piece of software upgrades doesn’t mean it includes any security content. The two problems are not tied to each other.

[adidalal]

As we're going off on a tangent here, I've moved over discussion to https://github.com/Homebrew/homebrew-cask/issues/47950.

Thanks, Aditya

[MikeMcQuaid]

This happened! Nice work @reitermarkus 👏