Update Bitcoin Cask for the 0.9.0 release and new naming

[fanquake]

No description provided.

[rolandwalker]

Why the name change?

[fanquake]

@rolandwalker Because the software has been renamed.

[rolandwalker]

Oh, I see that they are changing the branding per the web page. However, the app name is still so far unchanged.

Since #2659 @vitorgalvao and I have been hashing out a standardization for Cask names based on app names as the starting point. This is now formalized in a script developer/bin/cask_namer and document doc/CASK_NAMING_REFERENCE.md.

[fanquake]

@rolandwalker No, if you actually run the application, you see that it has been renamed throughout. Only the name of the actual .app hasn't been changed as yet.

I think this cask is one were we can make an exception to any rule. Having the cask named just 'bitcoin' doesn't make sense.

[rolandwalker]

When you say "doesn't make sense" -- I hate to disagree, because the truth is I don't disagree on UI.

In this comment over on #3280 I tried to outline a broad picture on naming and how it relates to development goals. Actually, the whole discussion there is constructive.

We are making Cask names answer to many different constraints:

• they are a user interface
• they are the sole search target
• they are directory names on disk
• they are unique IDs used by the Ruby backend
• they map to Ruby classes

and these constraints pull in different directions. Having the Cask named "bitcoin" works great from the point of view of the backend. And the backend literally cannot understand renames; it just drops them.

Having the Cask named "bitcoin" is poor/ambiguous on user-interface, I totally (strongly) agree. That is true not only of this Cask, but of many others, and will always be a problem because of the competing constraints above.

For the backend code, stability and predictability are the most important. And that is mostly resolved now (in #2659 and dozens of followups over the last two months). For the frontend, we can build out the UI in various directions to address the problem in a general way. Here are some recent merges in that vein: #3667, #2706.

It is also essential that brew cask search be able to target artifact names, URLs, tags (to be added), etc, and that brew cask search be able to display more than just the Cask name.

[vitorgalvao]

This issue would be solved if they changed the name of the .app, already. So why don’t we?

DEVONthink Pro Office has a good reason to have it’s target tweaked. Why not, in this case, link 'Bitcoin-Qt.app', :target => 'Bitcoin Core.app'? Granted, DEVONthink’s case is a particular one since the name we’re changing it to is the one users would see in Finder (just not in a terminal) if installed manually, so this could cause confusion for users expecting a Bitcoin-Qt app there, but since there has to be a compromise somewhere anyway (be it on the UI or on the backend), this could mitigate some of the confusion.

[rolandwalker]

@vitorgalvao agreed. But we must also defend against duplicate submissions.

[vitorgalvao]

Fair point, I hadn’t remembered that. However, since the app is branded as “Bitcoin Core” throughout (expect the .app itself), that should not be a huge concern, since calling it simply Bitcoin arguably causes some confusion as well.

[nanoxd]

What's the status on this?

[vitorgalvao]

I still feel like link 'Bitcoin-Qt.app', :target => 'Bitcoin Core.app' would be the best option. I’m guessing they aren’t in a hurry to change the name of the app upstream (which would solve our issue), so we should probably pick a resolution (including leaving it as is, which is just as valid) and close the issue.

[rolandwalker]

+1 on resolving by :target.

[vitorgalvao]

Submitted change, will let it sit a bit in case @nanoxd and/or @fanquake also want to chime in.