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 software1.
- 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.
1 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
.