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

"brew upgrade" should upgrade casks #16033

Closed
glyph opened this issue Dec 22, 2015 · 5 comments
Closed

"brew upgrade" should upgrade casks #16033

glyph opened this issue Dec 22, 2015 · 5 comments

Comments

@glyph
Copy link
Contributor

glyph commented Dec 22, 2015

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.

@adidalal
Copy link
Contributor

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!

@glyph
Copy link
Contributor Author

glyph commented Dec 22, 2015

@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?

@adidalal
Copy link
Contributor

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 brew cask upgrade" issues have been closed and pointed towards the above issue.

@glyph
Copy link
Contributor Author

glyph commented Dec 22, 2015

@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.

@vitorgalvao
Copy link
Member

#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 upgrade, it has been asked over and over since we started, and over and over we said that yes, it is a desirable feature.

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 update bedorehand, and if you ran it recently, having it coupled with upgrade is a waste of time and resources. This is one of those cases where you should make an alias, if you need it that much. Either way, it is definitly too soon to talk about, and there is definitely no point to leave open an issue that is a nitpick and easy implementation on a feature that doesn’t even exist.

@Homebrew Homebrew locked and limited conversation to collaborators May 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants