Skip to content
This repository has been archived by the owner on Nov 22, 2023. It is now read-only.

cask dymo-label versioning, potential user confusion #1381

Closed
jaakkopoyry opened this issue Dec 24, 2019 · 1 comment
Closed

cask dymo-label versioning, potential user confusion #1381

jaakkopoyry opened this issue Dec 24, 2019 · 1 comment

Comments

@jaakkopoyry
Copy link

Unsure if this qualifies as a pull request, or a bug, support issue, or none-of-the-above. Happy to tweak where necessary. Wanted to relay the info nonetheless.

Main concern

Potential user confusion & un-necessary uninstallation/reinstallation of Cask.
A user may expect v8.7.3 to be the end result after running brew cask install dymo-label & experience confusion upon seeing v8.7.0.331 in the /Applications folder.

Brew information

$ brew cask info dymo-label
    dymo-label: 8.7.3
    https://www.dymo.com/en-US/online-support
    /usr/local/Caskroom/dymo-label/8.7.3 (73.5MB)
    From: https://github.com/Homebrew/homebrew-cask-drivers/blob/master/Casks/dymo-label.rb
    ==> Name
    Dymo Label
    ==> Artifacts
    DYMO Label v.8.pkg (Pkg)

version numbers of installers & application

dmg via cask:                          8.7.3        "DLS8Setup.8.7.3.dmg"
dmg via manually download:             8.7.3        "DLS8Setup.8.7.3.dmg"

pkg via cask:                          8 	    "DYMO Label v.8.pkg"
pkg via manually download:             8 	    "DYMO Label v.8.pkg"

installed application seen by user     8.7.0.331    "DYMO Label.app"

Info.plist in the "DYMO Label v.8.pkg"
  <key>CFBundleShortVersionString</key>
  <string>8.7.0.331</string>

In fairness to the cask, it is functional and installs the latest dymo label software available for macOS, the same version as if one manually downloads it - 8.7.0.331 (as of this writing).

Potential Solution(s)

  1. brew side - adjust cask to reflect version of resulting app, not version of installer file.
    Is it possible to override the version currently shown in brew info with the version of the resultant app installed in /Applications?
  2. vendor side - cleanup erratic versioning
    Perhaps this is best fixed by the vendor by tightening up the disparate version numbers. It's just very confusing to an end user when the cask info reports 8.7.3 and they do not wind up with that version ultimately.
@vitorgalvao
Copy link
Member

2. It's just very confusing to an end user when the cask info reports 8.7.3 and they do not wind up with that version ultimately.

Mos users don’t care about the exact version, especially when just the patch is wrong. We use the version that can be interpolated in the URL, to make it simpler. If that’s wrong, it should be reported and fixed upstream.

@lock lock bot added the outdated label Jan 24, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Jan 24, 2020
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

2 participants