That probably happened since the versioning was changed from an explicit number (0.2.29) to simply “latest”. Does Calibre not auto-update?

Since the old link was broken and it is possible to get a link to the latest version, I think this is a better solution than having it break every time they increment the version by (literally) 0.0.01. This way, when first installing it you always get the most up-to-date version, and then it’ll update itself; unless of course it doesn’t actually check for updates, in which case we’d have to discuss what option seems to be the most acceptable.

Does the app warn you of new versions?

It checks for updates, but I have to manually download the dmg and install. And yeah their update system has always been like this, 0.0.01 increment every few days.

We're not hooked into brew upgrade right now are we? So the "upgrade" path is just to do brew cask uninstall && brew cask install.

Or am I missing something?

I don't know, but even brew cask uninstall && brew cask install should update it fine (which it didn't).
I now went through all my apps installed with cask, and noticed that brew cask list does not list the apps that had their .rb file changed (or so it appears). Meaning that I had to manually run the brew cask uninstall && brew cask install command for dropbox and vlc as well.

That’s something more prevalent earlier in the project, since even the syntax of casks is still under discussion, but it’s something we should probably look into.

That said, if you’re able to update calibre from now on with brew cask uninstall calibre && brew cask install calibre (should probably make that into a shell alias), then it seems to me the way it works now is better. Not only is it easier and faster for you to do (running a command vs having to go to the website and get the new version), it’s also more future-proof, as we won’t have to update the cask every couple of days.

I thought this should be automatically executed with brew upgrade for outdated cask apps.

I think a brew cask upgrade command is probably in order.

There's a larger question about whether we should attempt to hook into homebrew commands (#44), which would give you brew upgrade integration. I'm still sort of skeptical about that notion, though.

If you were able to issue a brew cask upgrade command, would that meet your needs?

As you know, I employ homebrew-cask a little differently from the way it’s intended, so either way will not affect my workflow.

That said, from a usability perspective won’t brew cask upgrade be a bit confusing, seeing as brew update functions as expected? It’s like I can already feel the multiple open issues at various points in time asking about this (cue TextExpander snippet, to explain how it works). I believe the commands can work either way, either with cask or without, but they should be consistent, i.e. either brew update and brew upgrade or brew cask update and brew cask upgrade. There’s also another kind-of solution, which would be to have brew cask upgrade and alias brew cask update to simply call brew update (although this could be a bit confusing in itself, seeing as the command would also update homebrew, but I think it wouldn’t be as confusing).

Yes, brew cask upgrade is perfectly fine. I'm already using an alias for all system update commands so including this will be no problem. But I have to agree with @vitorgalvao, this could prove to be confusing to some users.

Suggesion for the brew cask upgrade command code:

#! /bin/bash

caskApps=( $(ls /opt/homebrew-cask/Caskroom/) )
caskList=( $(brew cask list) )

diffs=()
for i in "${caskApps[@]}"; do
    skip=
    for j in "${caskList[@]}"; do
        [[ $i == $j ]] && { skip=1; break; }
    done
    [[ -n $skip ]] || diffs+=("$i")
done

if [ $(echo ${#diffs[@]}) -eq 0 ]; then
    exit
elif [ $(echo ${#diffs[@]}) -gt 1 ]; then
    s="s"
fi

difList=$(printf ", %s" "${diffs[@]}")
difList=${difList:1}

echo -e "==> Upgrading ${#diffs[@]} outdated cask$s, with result:\n$difList\n"

for i in "${diffs[@]}"; do
    brew cask uninstall "$i"
    brew cask install "$i"
done

What do you think?
Edit: I get warnings:

Error: APP_NAME is not installed

With this script, and older versions are not removed.

I suppose that's pseudo-code, as you'll have undoubtedly noticed we use Ruby? For the less bash-savvy, do you think you could provide a less line-noisy alternative?

This is bash, I don't know ruby.
Basically it computes an array "diffs" with cask names that are installed in /opt/homebrew-cask/Caskroom/ but not shown in the output of brew cask list command, and then performs an "update" for each application in array - brew cask uninstall and brew cask install.

Even in bash, that could be way less verbose. No need for the arrays.

#!/bin/bash

caskApps=$(ls /opt/homebrew-cask/Caskroom/) # Lists the casks in the Caskroom

for app in ${caskApps}; do # For every app there, do this
    appToCheck=$(brew cask list | grep "${app}") # If the app is not present in `brew cask list`, this variable will be empty

    if [[ -z "${appToCheck}" ]]; then # If the variable is empty, then
        brew cask install --force "${app}" # Force an install of the app
    fi
done

haha well let's not refine the bash too much before we convert it to ruby! 😺

i do this the general logic that you suggested seems good @shrx - we essentially need to get smarter about detecting if any version is installed. i think we'll probably be modifying the definition of Cask#installed? and then maybe adding Cask#installed_version - then we can drive the upgrade process from those two concepts.

of course for latest casks we'll need to decide if the upgrade command should always attempt upgrade or warn or ignore.

Do we still want this? Also this discussion and #316 are related.

Yup - I think we do. I'm going to edit the original issue so the title is clearer.

Just a note, running brew cask uninstall calibre && brew cask install calibre will reinstall the last downloaded version from the cache. This works:

rm -r `brew --cache`/calibre-latest && brew cask uninstall calibre && brew cask install calibre'

How can I update all the applications installed with cask?
Should I manually run brew cask install for each one of them?

@licx That alone will not work (see @lmergner’s comment). What you would need to do is clear homebrew’s cache and force install all of them. The following (untested) should do it.

rm -rf "$(brew --cache)"
brew update

for app in $(brew cask list); do
    brew cask install --force "${app}"
done

For my concern, most of the app update themselves, so I don't worry about that. Also, checkout Bodega.app :)
But it's an interesting point.

+1 for brew upgrade to update Casks as well.

Yeah. brew upgrade should do cask as well, if no important reasons prevent it.

Until then I'm using the solution by @sgtpep.

Also +1 for brew outdated to show which casks will be upgraded.

Mind a tiny bit blown that this isn't a key feature provided out of the box...

@itsthejb Homebrew-cask is alpha software, in part, exactly for this reason. Anything I might add has already been said in the last two paragraphs of my previous comment.

@vitorgalvao, apologies for seeming a bit blunt, there - been a long day 👍

Not at all, you comment was clearly not malicious. Just wanted to reinforce that this is still very much on the radar.

+1 for brew cask upgrade and brew cask outdated, i don't want two versions of alfred ( 2.1, 2.3)

+1 for brew upgrade

+1 for brew upgrade and brew outdated

+1 for brew upgrade and brew outdated

+1 for brew cask (upgrade|outdated)

+1 for brew upgrade

Hi everyone, I'm a relatively new cask user (<2 months), and I've also been frustrated with the lack of a "brew cask upgrade" command, so I wrote a short Ruby script that seems to get the job done. It's kind of a hacky approach to the problem (i.e. grepping through the "brew cask info" output and comparing it to what's in the directory of the installed cask), but it seems to work reasonably well, so I figured I'd post it here to see what you guys thought (I'm also relatively new to Ruby, so my apologies if my style is really off or I unwittingly broke some best practive rule).

# Location of casks
CASKROOM = '/opt/homebrew-cask/Caskroom/'

# Go through installed casks.
Dir.foreach(CASKROOM) do |cask_name|
  # Ignore hidden files/directories (i.e. '..' and '.', although someone could
  # potentially have others, such as ".DS_Store" if they've trashed anything
  # there).
  next if cask_name.chr == '.'

  # Get the info for the cask and find the newest version.
  cask_location  = File.join(CASKROOM, cask_name)
  version_line   = %x(brew cask info #{cask_name} | grep #{cask_name}:).split
  newest_version = version_line.map(&:strip).last

  # Get the list of installed versions from cask directory. As before, ignore
  # any hidden files.
  cask_dir_contents  = %x(ls #{cask_location}).split.map(&:strip)
  installed_versions = cask_dir_contents
  installed_versions.reject! { |file_or_dir| file_or_dir.chr == '.' }

  # Remove any old versions.
  installed_versions.each do |version|
    next if version == newest_version
    %x(mv #{File.join(cask_location, version)} ~/.Trash)
  end

  next if installed_versions.include?(newest_version)

  # Install newest version if it's not already installed.
  system("brew cask uninstall #{cask_name}")
  system("brew cask install #{cask_name}")
end

Hi @saghmrossi!

Yes, many of us are relying on similar scripts for the time being while working on #4678. It will work most of the time, which is good enough for personal use.

But this is a busy project. If we deliver a "brew cask upgrade" that fails 10% of the time, we will be positively flooded with bug reports.

Thanks for posting your solution for others. See also https://github.com/caskroom/homebrew-cask/blob/master/developer/examples/brewcask-doutdated.rb .

👍 for brew cask (upgrade|outdated)

Just found out about brew cask, was really excited for an easy way to manage my software that doesn't automatically update up-to-date. This is an awesome program from what I have seen, however adding a brew cask (upgrade|oudated) command would make this even better!

The issue is now locked since it currently consists mostly of sporadic votes for the feature. To be clear, the feature will be implemented (barring unforeseen circumstances), and is being tracked in #4678.

This issue will be kept open since many people still find this discussion, it has important points, and, well, it’s not solved yet, after all.

Thank you all for the discussion.

Closed in favor of #4678, since we haven’t had problems with duplicates with this.