-
-
Notifications
You must be signed in to change notification settings - Fork 10.7k
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
"brew upgrade" should upgrade casks #16033
Comments
It's been discussed, quite a bit The long and short of it is, the change in behavior from linking to moving will making implementing this a lot more feasible. For the time being, me (and many others) use scripts to achieve the same thing. Nothing's officially endorsed (or else we would have implemented it), but check #13256 for ideas. I personally use brew-cask-upgrade but it's fragile and won't update things with :latest, for that you need to uninstall && reinstall .... As you can see there are plenty of problems with any approach, but at this point it's best-effort. That being said, if you find yourself inclined to help working on this issue open up a PR with some code and we can go from there! #15908 is also working towards streamlining updates, but on the maintainer side (reducing the time from when an update is released to when we can have it in homebrew cask). Hope this answers your questions! |
@adidalal - thanks for all the links! one thing I'm slightly confused about - if this is desirable functionality, which issue is this a duplicate of, that is the one I should follow for future discussion of an upgrade-all command? |
After #13201 is done, we’ll be able to start working on an upgrade solution. Until then, there is no official method for upgrading homebrew casks. I'll let @vitorgalvao decide if this issue should be reopened, as I believe all the" implement |
@adityadalal924 - The software-process nerd in me feels like there should be a single open issue for the upgrade issue itself, as opposed to #13201, which (if I understand properly) is just infrastructure potentially useful for that goal. |
#13201 is everything related to the new behaviour, including upgrade functionality. All the changes mentioned there are related and make sense being bundled together. Separating them accross issues for now serves no purpose and makes things harder to manage for us. We don’t need an issue to be reminded of We need less open issues, not more. Issues aren’t a good organizational tool, they’re a jumbled mess of ideas that have to be combed through periodically. I always know when a maintainer is going through them all because I suddenly get a bunch of emails of decrepit no-longer-relevant or solved-but-left-open issues being closed. It’s rewarding to do that and see it happen, but it just emphasizes how too many issues is harmful. We know it first-hand. As for the point of this issue, the answer is simple: we’ll emulate what homebrew does. Makes sense, since we’ll join up. I think your suggestion is a bad idea, though. It isn’t that much effort to just have |
It would be nice to reduce the overall amount of user interaction required to upgrade things. In fact, I've been making a concerted effort to switch to Cask instead of installing applications myself, specifically because at least then it's possible to have a central idea of which applications are installed, and update them all at once when connected to a nice high-bandwidth connection, without manually clicking through a bunch of release-notes dialog boxes. (I have 4 macs I interact with regularly, and doing this 4 times in a row is tedious beyond belief ;)).
As a first step perhaps we could have a "brew cask upgrade" that upgrades things that have new versions available.
The text was updated successfully, but these errors were encountered: