As discussed at the AGM:
- Only allow formula/cask forks to be used when either blessed by
the source or used by two other major distributions,
- Further elaborate and tweak reasons to deprecate/disable formulae.
- Allow more versioned formulae when widely used.
- Add a document (based on above) for deprecating/disabling casks.
While we're here:
- let VSCode Markdown linting remove the trailing `!` from an
Acceptable Casks heading
We discussed the idea of adding a livecheck strategy to check crate
versions years ago but decided to put it off because it would have
only applied to one formula at the time (and it wasn't clear that a
crate was necessary in that case). We now have a few formulae that
use a crate in the `stable` URL (`cargo-llvm-cov`, `pngquant`,
`oakc`) and another formula with a crate resource (`deno`), so
there's some value to the idea now.
I established a standard approach for checking crate versions in a
somewhat recent `pngquant` `livecheck` block update and this commit
reworks it into a strategy, so we won't have to duplicate that
`livecheck` block in these cases. With this strategy, we usually
won't even need a `livecheck` block at all.
Under normal circumstances, a regex and/or strategy block shouldn't
be necessary but the strategy supports them when needed. The response
from the crates.io API is a JSON object, so this uses
`Json#versions_from_content` internally and a `strategy` block will
receive the parsed `json` object and a regex (the strategy default or
the regex from the `livecheck` block).
- This diagram was really old and didn't reflect the current practices
(a lot more things are automated now, hurray).
- Anything we replace it with will get outdated fast too.
- Also delete the diagramming docs since I don't believe we have made
another diagram since this one which got out of date and forgotten
about since it was a DrawIO SVG and not easily editable as code.
- If we want diagrams these days, we can use Mermaid which is
diagrams-as-code.
- We don't need this blanket enabled, we only have a few docs where it actually matters that there's a description, it's just cruft having to invent descriptions.
- Yes, we have yet another `.rubocop.yml` but in-line exclusions in
`<span class="display:none;">` in the Markdown seemed more ugly.
- This needed tweaks to `brew style` to make it read the new config
file when we're scanning docs.
- Blocks should open with `do` and close with `end`.
- `...` is not valid Ruby syntax, so comment it out so that the user
knows that it's a placeholder for "other things here".
- Reword the "header line details" in `Cask-Cookbook` otherwise RuboCop
crashes even with an `end` because of the empty block. There was
already an example of a valid header line in the first code block on
the page, so it's not a big loss.
