Rules for what to include in this repo

[vitorgalvao]

Pinging @caskroom/maintainers.

To put it bluntly, this repo is a dump. While thinking of how we could organise it better, I though we perhaps needed a few more repos, but this actually has a small number of casks (under 350), so we’re well in time to make it manageable.

What I see as part of the issue is how just about any old version gets included, for any reason. The recent submission of an old version of Go is a good example. This has marginal hypothetical benefits and will end up being a neglected cask, and I believe we should not include it. This is also true for a truly ridiculous amount of old firefox versions. For most of these, there isn’t anything close to a significant demand for them or clear advantage to including them and hence should not be officially supported by us.

My proposal for the rules of cask inclusions in this repo is as follows (following our nomenclature):

• Include the latest minor version of legacy versions of commercial and freemium software¹.
• Legacy versions of commercial and freemium software are restricted to a maximum of five casks.
• Include beta, development, unstable, nightly, early access program, ….
• Include language and regional versions other than US english.
• Include alternate versions (Firefox Developer Edition, Community Editions, Pro versions).
• Refuse legacy versions of gratis or open-source software, unless there is a clear demonstrable need for them.
• Legacy versions of gratis or open-source software that were accepted should be removed after one year.
• Include casks that do not fit the rules, but need to exist somewhere since they are required by other casks.

Some reasonings:

There is a clear demand and reason to include legacy versions of commercial software — you don’t want to or can’t spend the money to get the latest version. However, for gratis and open-source software, this restriction isn’t there, and many times specific versions are submitted simply to solve a specific gripe of that particular user or without a clear purpose, and we should avoid those cases. Do we really need so many versions of Virtualbox? No, we do not. However, sometimes there might be a good reason to include these, like the latest stable breaking something important, in which case those should be fine to include. The time one year limit (arbitrary, until we can try it out and see what works) exists to ensure we have a clear rule to keep these in check.

For casks that we refuse, we should recommend taps. They are a wonderful system that works great, and is taylor-made for those cases.

---

¹ So if we’re at version 8 of VMWare Fusion, legacy versions are, for example, 6 and 7. If the latest released versions for those were 6.3.4, 6.8.5, 7.8.2, 7.9.1, only the 6.8.5 and 7.9.1 should be included. Versions should only contain one number, the major version, so the casks would be vmware-fusion6 and vmware-fusion7, not vmware-fusion685 and vmware-fusion791.

[adidalal]

We should also encourage the use of the main repo for cases where an old version of software is required for a specific OS and remove them from this repo.

Maybe adding an example of a standard if/elseif to handle that scenario would be useful to add into the cask language reference, as it will also encourage consistency when creating conditionals.

An example I just removed is #1451

[vitorgalvao]

We should also encourage the use of the main repo for cases where an old version of software is required for a specific OS and remove them from this repo.

I know which cases you’re referring to, and those actually do usually warrant a version here, due to being commercial versions.

[adidalal]

Casks which seem to need cleanup

• chefdk036.rb - very old version
• clipmenu-alpha.rb - doesn't even seem to be on official site
• diskaid.rb - discontinued product
• dockermachine010.rb - very old, likely abandoned (a suitable version would be v0.5.x range)
• instacast1.rb - site down (discontinued)
• keyremap4macbook-mountainlion.rb - needs to be renamed or merged into Karabiner cask
• kobo-jp.rb - discontinued
• microsoft-office-preview.rb - is now official version
• mondomouse.rb - requires Mac OS X 10.5 or 10.6.
• writeroom2.rb - app moved to MAS

(Not a comprehensive list)

[fanquake]

There are more casks than in that list that can be removed. I don't have time to list them all out now, but I can start culling them over the next few days.

[vitorgalvao]

Please keep in mind all of these rules are a proposal. If anyone has an objection to them, please feel free to say so.

[adidalal]

Thoughts on removing python versions? Tools like https://github.com/yyuu/pyenv seem to take care of this need, and as such, we aren't a package manager.

[fanquake]

They are also failing the cask audit.

[fanquake]

Charles Open-JDK could also be up for deletion, I can't seem to find a newer version of it.

[vitorgalvao]

If there’s a language that would warrant having various versions supported by us is Python (2 and 3), but I agree that should be taken care of by a dedicated tool (and we should always support the latest version).

In the end, though I could see the case for having both versions, but I’m sure the python developers would appreciate if we didn’t perpetuate the endless case of having version 2 officially supported.

Fine by me if we removed them, but I wouldn’t mind that much if we kept them. Since they’re failing audit, though, why not.

[fanquake]

Some of the Vagrant & Vagrant manager casks are candidates for removal

[bdhess]

I don't have a lot of skin in the game, but I would argue for an exception for SDKs, where there may be breaking changes between versions. As an average user I normally expect multiple versions of SDKs to be available in my package manager, and I'd prefer not to use an external version manager.

To follow on the Ruby example mentioned in #1446, using some other source like rvm involves downloading a script from the interwebz, verifying third party PGP keys, consulting a manpage to refresh my memory on its syntax, and then ultimately sideloading a Ruby version from a source other than my normal trusted package manager.

homebrew-versions contains multiple versions of GCC, llvm, Perl, Ruby, and so on as do the central repos for most linux distros. Heck, there are so many versions of PHP and its associated packages that there's a whole (Homebrew-maintained) tap for them.

[vitorgalvao]

but I would argue for an exception for SDKs, where there may be breaking changes between versions.

Those are part of the plan, covered under the rule (emphasis added):

Refuse legacy versions of gratis or open-source software, unless there is a clear demonstrable need for them.

I’ve also expanded in the text:

Do we really need so many versions of Virtualbox? No, we do not. However, sometimes there might be a good reason to include these, like the latest stable breaking something important, in which case those should be fine to include.

So those should be fine, but should be removed after one year (arbitrary number, until we get some real use cases).

Regarding the Ruby example, it can indeed be a matter of personal preference, so I won’t argue there, but I’d like to address he trust point, since that seems (perhaps I’m reading that wrong) like a concern for you. How are we different from rvm in that regard? Were we officially integrated into the OS (like Linux package managers) I could see the case for that, but in the end we’re just a script you download from the internet, just like rvm.

[jawshooah]

I'd also point out that if you want a Ruby version manager that's a bit less involved than rvm, rbenv works very well.

[vitorgalvao]

Or ruby-install with chruby (my preference).

[bdhess]

@vitorgalvao - if the 'clear and demonstrable need' rule covers the points I'm trying to make about SDKs, then I would think it would make sense to accept #1446. In Go, binary compatibility isn't guaranteed between releases. I assume it's for this reason that homebrew-versions contains packages go12, go13, and go14 (built from source). As further ammunition for this particular case: Go 1.4.3 was released on 2015-09-22, after the release of Go 1.5.0 on 2015-08-19.

I think this pattern is generalizable to most SDKs/languages-- that even when a new release is cut, the previous release continues to be supported and patched for some period of time, and there are legitimate reasons to continue to use it. There may be breaking contract changes, there may be different performance or runtime characteristics, your code or a library you use may rely on an implementation detail that has changed, third party tooling/support may not yet be ready, time must be allotted for adequate testing of an existing codebase under the new release, and so on.

I think the question of trust is interesting. As a user of Homebrew and HBC, I've elected to trust the ecosystem on some level. Much of that is based on having learnt how it works, and having observed the quality and attention to detail that's been evident in all of my interactions with the maintainers. As someone who only rarely works in Ruby and doesn't have a preferred version manager, but who often uses HBC, I do trust HBC more than the top Google result for ruby version switcher or whatever the appropriate query is. To me, the key feature of HBC is that it automates the process of retrieving and installing vendor-provided binaries from the vendor's official download site. I assume that that's not the case with tools like rbenv or chruby, as AFAIK the Ruby team doesn't actually produce binaries for OS X. But it is the case with Java, and Go, and Python, which is why I think it's appropriate to host these Casks, previous supported versions included, somewhere in the Homebrew hierarchy.

[jawshooah]

I assume that that's not the case with tools like rbenv or chruby, as AFAIK the Ruby team doesn't actually produce binaries for OS X

Sorry if this is a bit of a derailment, but just to be clear: the Ruby team endorses rbenv and rvm as methods of installation, so it's probably okay to trust them.

homebrew-versions contains packages go12, go13, and go14 (built from source)

To me, this is a strong reason not to include these packages here. We have already begun an effort to remove casks which duplicate Homebrew formulas, as we have plans to integrate directly into Homebrew.

The same goes for Python. Homebrew already distributes the latest versions of Python 2 and 3, and tools like pyenv (based on rbenv) and conda are available for more granular version management.

Java is a different beast, since AFAIK there isn't a (widely used) CLI tool for installing and managing different versions. I'm fine with keeping the Java casks around.

[bdhess]

To me, this is a strong reason not to include these packages here. We have already begun an effort to remove casks which duplicate Homebrew formulas, as we have plans to integrate directly into Homebrew.

I was more reacting to the apparent disparity in treatment for the previous version. There's still a Cask for go (1.5); I suppose that should be slated for removal?

I think there are also cases where I'd prefer to be running the vendor's binaries than compiling from source, or retrieving a bottle produced by the Homebrew test bot. There may be support implications, for example. I don't know if that's been considered in the integration plan.

[jawshooah]

I think there are also cases where I'd prefer to be running the vendor's binaries than compiling from source, or retrieving a bottle produced by the Homebrew test bot.

That's definitely something we should discuss. Feel free to chime in on Homebrew/homebrew-cask#15603, as I think it's more appropriate there.

There's still a Cask for go (1.5); I suppose that should be slated for removal?

I suppose that depends on the outcome of the discussion mentioned above.

[MikeMcQuaid]

Homebrew Versions has just changed our submission guidelines (thanks @DomT4) to make it also less of a dump: https://github.com/Homebrew/homebrew-versions/commit/992b05c6e55e23a75ee5ae3a684624f7057cc8ad. You may be interested in similar policies or tweaking that to meet your use-case.

AFAIK the Ruby team doesn't actually produce binaries for OS X

As an aside, if anyone feels like working on a side-project to provide decent binaries for ruby-build or ruby-install to be pointed to I'd be game to help. It makes me sad how much CPU time is wasted recompiling the same stock Ruby versions and producing identical OS X binaries.

[vitorgalvao]

Thank you @MikeMcQuaid. That was useful in tweaking the wording and for the introduction.

Rules added on #1504. Closing this.