rename hockeyapp.rb to hockey.rb

[rolandwalker]

to conform with naming conventions.

It seems we have visited the naming here before in #4286, but not covered Remove the term "app" from the end, if the developer styles the name like "Software App.app".

[tapeinosyne]

This cask is an ambiguous case. The “App” suffix:

• is consistently included in their branding;
• may be more than stylistic, as HockeyApp appears to be an app development/distribution service.

[rolandwalker]

We can further clarify the docs on this. It's not ambiguous, according to the naming algorithm.

Whether the suffix appears in the branding is purposefully ignored. Matters of interpretation, such as the meaning of "app", given the vendor's business model, are purposefully ignored. We only allow one type of exception, where the stripping of a suffix would cause the Cask name to become literally nonsensical: playonmac.rb does not become playon.rb.

The naming conventions are rigid, but they aren't rules-for-the-sake-of-rules. We suffer a technical limitation in that we can't track renaming events, which is about to become more important with brew cask upgrade. Removing interpretation from naming minimizes re-naming (over the course of the project).

It also protects us against duplicates, which did exist prior to normalizing names.

The Cask name is being asked to do too many things. The most fundamental and non-negotiable is to be a regular, predictable, unique name for use in the filesystem in the staging area.

The constraint that it must map to a Ruby class name is being removed via the new header. Mapping to the complexities of branding is at odds with being predictable: thus the addition of tags :name.

Speaking of which, this Cask should have a tags stanza, so that we can capture the full branding and make it searchable/displayable.

Another missing piece is that brew cask search should strip the same suffixes from search terms, so that brew cask search hockeyapp finds hockey. To do that, the cask_namer logic should be merged into the main codebase.

[tapeinosyne]

My principal concern is that unforgiving rules for internal consistency may lead to confusion. (E.g. it is unclear that hockey is HockeyApp, without an additional brew cask info.) A non-destructive way to address the issue would be to favor “human-friendly” names in the user interface, where feasible.

[rolandwalker]

It's absolutely a compromise, and we very much need to work on the user-facing interface for tags.