This tool checks if for a given HTTP url (url, appcast,
homepage stanza), the HTTPS variants lieds to an existing Page
(HTTP-Status 200, valid certificate chain). If it does the cask
is updated accordingly.
This provides a few benefits:
- faster `brew cask` execution times as another Ruby process is not
needed. Cask can instead be loaded in-process with Homebrew. This
will also make it easier to use some of Homebrew's core code and
ease moving code from Cask into Homebrew core.
- Users do not need to `brew upgrade` Cask any more: it's done
automatically on any `brew update` or `git pull` of the Cask tap.
This script runs `brew cask audit` on any Casks added or modified in the
given range of commits. If the `url` or `sha256` stanzas have been
modified and `sha256` is not `:no_check`, run the audit with
`--download` to verify the checksum.
* convert existing Cask:: namespace to Hbc::
* move Homebrew-fork code under Hbc::
* move freestanding classes such as Tty and TopologicalHash under Hbc::
* recast HOMEBREW_CASK_ constants as HBC_
* modify our Homebrew Formula for backward compatibility
* devscripts and dev docs
It was just carelessness that this script was written in
a way limited to Ruby 2.0, but we may as well be explicit
about that pending a fix.
closes#8021
Class names are now completely hidden from the user. This
commit works by adding a prefix to all Cask class names, which
is considered to be an ugly transitional hack on the way to
representing individual Casks as instances.
* "Canonical App Name" becomes "Simplified App Name"
* devscript `cask_namer` renamed to `generate_cask_token`
* doc file `CASK_NAMING_REFERENCE.md` renamed to `cask_token_reference.md`
* DSL uses `"#{token}"` for interpolation instead of `"#{title}"`
* documentation text
* backend code (variables, method, class names)
* error message text
* tests
* code comments
* Cask comments
* emphasize `tags :name`
* doc: use "vendor" consistently instead of "developer"
* doc: many man page argument descriptions were incorrect
* incidental clarifications
Many backend variables similar to `cask_name` or `cask` have
been standardized to `cask_token`, `token`, etc, resolving a long-
standing ambiguity in which variables named `cask` might contain
a Cask instance or a string token.
In many places the docs could be shortened from "Cask name" to
simply "token", which is desirable because we use the term "Cask"
in too many contexts.
Vítor Galvão