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
Deprecate homebrew-cask-versions and migrate casks to homebrew-cask #112102
Comments
I am generally in favour of doing this. We will need a way of handling the different versions (ie. beta, nightly, etc..) in the main cask repo. In the cases of legacy major versioned casks, we will need a syntax there as well. Not sure on the pros and cons of the It is probably worth discussing merging |
I think it'd be good to be consistent unless it's overly laborious in terms of code changes required. |
Agreed. I'd love to see us get down to ideally a single |
Looking at most of the casks in cask-versions they either have a major version number (e.g It would be good to agree on a standard for beta builds. With legacy builds I feel the simplest way is to use the semver major approach (e.g I would suggest that we begin by migrating all of the versioned casks (as they seem to be the simplest to carry over and then look back round for the remaining casks? |
I agree that standardised naming conventions are the best option. We will need to consider instances (there's only a couple) that have multiple variants available,
This is currently how the casks are named, however it isn't consistent with |
So let's say we decided to rename the versioned ones to (e.g |
I'm not sure what the cask support is like for renaming. It was implemented for formulae but not sure if it ever was for casks. |
Yeah it looks like we'd need to add support for Aliases to homebrew-cask (which wouldn't be a bad thing to do TBF) |
I'd rather see these merged before we block on renaming. With that in mind: I think we should just keep the existing names. |
I can take a look at adding support for Aliases? I've never looked at the actual CLI codebase in my life but this would make the migration 100 times easier (and cleaner) |
@gdams you're welcome to take a look. I'd suggest instead of aliases that you look at https://github.com/Homebrew/homebrew-core/blob/master/formula_renames.json and the relevant code that handles it ( |
(note: renames add implicit aliases) |
Instead of aliases, we should get the equivalent to
The (current) standard is what upstream calls it because it’s simple and allows the same software with multiple variants. Regarding |
@MikeMcQuaid / @vitorgalvao are either of you able to point me in the rough direction where such a code change might be made? I'm trying to locate where the existing |
👍🏻 and it brings aliases for free
👍🏻
@gdams best bet is to ask in Slack, I'm snowed under personally. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
In homebrew-cask-versions, there are some casks not using official download links due to unstable appcenter links like I have a proposal #107354 before to add a new Should these cases be considered? |
@JounQin Can you elaborate what is meant by "unstable" here? Thanks! |
@MikeMcQuaid Take https://github.com/Homebrew/homebrew-cask/pull/86109/files#diff-3613a5c84fb0ae218d5189a6432b5d06ba33680109ff8fd9fb0f4e7fd11bdc44R6 as example, its download url will be invalid after a few minutes. |
@JounQin Yeh, that seems not great. A |
If a If there are more, they need to be corrected; we don’t want non-official links. @miccal You merged this one, do you remember? None of this precludes an |
Yes I do remember, and I recall being surprised that this one was "stable". And it still is, it seems:
I opened an issue with Microsoft at this user's request, but it was never answered and I closed it after a month or two. |
IMO the scope here should expand to "migrate casks from all homebrew-cask-* repos into homebrew-cask" |
Reminder that moving the drivers repo without a pre-selection could be messy (last paragraph). The fonts repo is probably worth keeping separate: it has a ton of casks but they are not of interest to everyone and its repo management is mostly automatic. |
Is this still open? |
https://github.com/homebrew/homebrew-cask-versions has not been archived so it should stay open. |
@Homebrew/cask We are hoping to move forward with the migration of The current step is to lock in a naming convention for consistency. Proposing that we go with The advantages are that it keeps the naming convention in line with |
Just for context for anyone following along: drivers was migrated and archived 🎉 |
``` $ brew info --cask google-chrome-canary Warning: Cask homebrew/cask-versions/google-chrome-canary was renamed to google-chrome@canary. ==> google-chrome-canary: latest https://www.google.com/chrome/canary/ Installed /opt/homebrew/Caskroom/google-chrome-canary/latest (61.4KB) ==> Name Google Chrome Canary ==> Description Web browser ==> Artifacts Google Chrome Canary.app (App) ``` Refs. - Homebrew/homebrew-cask-versions#20186 - Homebrew/homebrew-cask#172349 - Homebrew/homebrew-cask#112102
Provide a detailed description of the proposed feature
Now that we have enough automation in place, I propose that we deprecate homebrew-cask-versions and either migrate or deprecate (on a case-by-case basis) the casks that are listed there.
CC @MikeMcQuaid @vitorgalvao
What is the motivation for the feature?
From a maintainers point of view, maintaining two repos is more work than just one. There are only a small number of casks listed at homebrew-cask-versions and by migrating them to this repo we improve the end-user experience (by not needing to tap cask-versions).
Example use case
n/a
The text was updated successfully, but these errors were encountered: