Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: prepend vendor on naming collisions #3344

Closed
rolandwalker opened this issue Mar 3, 2014 · 3 comments · Fixed by #3362
Closed

proposal: prepend vendor on naming collisions #3344

rolandwalker opened this issue Mar 3, 2014 · 3 comments · Fixed by #3362
Assignees

Comments

@rolandwalker
Copy link
Contributor

@vitorgalvao , after #3305, it seems we are finished with the scriptable part of Cask naming. The number of link Casks remaining which don't follow the rules is 17, roughly as predicted.

While this is fresh in my mind, I'd like to nail down a couple more rules for the documentation.

There are three cases (six Casks) where Cask names collide due to coincidence, not forking (or would collide, if we followed naming rules):

First of all, I propose that we try to avoid the case where a Cask name differs only by the placement of a hyphen.

Second, for the general question of a disambiguating a collision, I propose that instead of appending descriptive text (eg unison-usenet.rb) we prepend the vendor name: panic-unison.rb). We should use our judgment to select the oldest/most popular software to remain as unison.rb.

Reasoning:

  • follows industry norms: "Google Chrome", "Adobe Reader", etc
  • less likely to lead to duplicate submissions, b/c it is less subject to interpretation
  • same rule may also be applicable to forks
@vitorgalvao
Copy link
Member

Agreed. Sometime we won’t really have a choice in which one gets the prefix (f.lux and unison do not have a recognisable vendor name to attach, while the alternatives do).

In the specific case of the webp plugins, they seem to not be a fork of each other, and be roughly equal in popularity (considering the number of users watching and stars). The one linked in webpquicklook.rb seems to be slightly popular by these metrics, while the one linked in webp-quicklook.rb appears first in google’s results (these varie depending on who is searching, so might not be the best way to evaluate this), in duckduckgo, and bing. They’re also not that far apart in age, so it’s a shame to pick one to not have prefix over the other. However, prefixing both seems a bit weird (and could possibly lead to duplicate submisions anyway), and I do agree we should have some rule.

For this particular case, I think the one currently named webp-quicklook.rb should be the unprefixed one — it seems to appear first in search results, it’s older, and the user seems to be more active on github (more projects, more stars on each, and more public contributions overall), so it will likely be more recognisable.

@rolandwalker
Copy link
Contributor Author

Agreed. Will implement the relevant changes tomorrow-ish.

Thanks so much for continuing to consult with me on these deadly boring details.

BTW the bundle ID for an app always supplies a "vendor", though people can write whatever they want there so long as it is unique. For f.lux we could extract "Herf" as the vendor via the bundle ID. I think that is indeed a nick for the author, but it wouldn't be helpful to users. Luckily we don't have to make that call in this case.

@vitorgalvao
Copy link
Member

Thank you as well for always pinging me on this proposals.

Right, I forgot about the bundle ID to check for that.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants