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

version numbers instead of latest for updating #32074

Closed
tiiiecherle opened this issue Apr 7, 2017 · 3 comments
Closed

version numbers instead of latest for updating #32074

tiiiecherle opened this issue Apr 7, 2017 · 3 comments

Comments

@tiiiecherle
Copy link
Contributor

tiiiecherle commented Apr 7, 2017

Hey,

first of all thanks for this very nice project, really good job.

Yesterday I submitted some version updates from "latest" to the real version number incl. the checksums. They were closed here

#31988

due to "no need for all those changes if the download URL doesn't point to any specific version".

In my opinion there is a big win in changing all latest to real version numbers if you use brew cask not "only" to install, but to update the apps.

I put together a script and an app that takes cake of it and I´m using it quite often and it works well.
https://github.com/tiiiecherle/osx_install_config/blob/master/05_homebrew_and_casks/5c_brew_casks_update/bash/brew_casks_update.sh

app version in the dmg is here
https://github.com/tiiiecherle/osx_install_config/tree/master/05_homebrew_and_casks/5c_brew_casks_update

From that point of view it makes great sense to eliminate as many "latest" versions as possible as the script checks for changes in the version number to update. If it stays at "latest" it can never be recognised as "updateable" by the script.

Perhaps the script could even be referenced to or something to help others.

Free for discussion ;)

I would like to submit all the changes from yesterday again after that said. Please let me know if this is ok. And I´m happy and open to all contributions and / or thoughts to my update script.

Kind regards

@miccal miccal added the awaiting maintainer feedback Issue needs response from a maintainer. label Apr 7, 2017
@vitorgalvao
Copy link
Member

vitorgalvao commented Apr 7, 2017

no need for all those changes if the download URL doesn't point to any specific version

“No need” might not have been the best wording.

The thing is we reliably can’t have those casks versioned because we have no reliable way to know when upstream changes the target of that url, and to what. If we keep those versioned and with a sha256, they will constantly break.

That is why casks with an unversioned url but that have an appcast still have version and sha256 set. Because the appcast allows us to see changes. Users made their preference for versioned casks known. When we don’t have them, is because we can’t (while not providing a breaking crap experience).

As for updating, that’s why #29301 exists.

@miccal miccal removed the awaiting maintainer feedback Issue needs response from a maintainer. label Apr 7, 2017
@tiiiecherle
Copy link
Contributor Author

Thanks for the feedback, that is exactly the point. Even if they break they should all have versions. The upgrade option wouldn`t detect that there is an update available if "latest" is used. And noone wants to download and reinstall all "latest" versions on every update run to be sure you are up to date.

A lof of casks like teamviewer, onyx, etc., have been updated to versions which is very nice und updates are coming in constantly.

Yes, it would be a little more updating maintenance, but it would be way better functionality.

Just let me know if it would be ok if I re-add pull requests for these few casks.

Thanks in advance

@vitorgalvao
Copy link
Member

Yes, it would be a little more updating maintenance, but it would be way better functionality.

No, what it would be is a crap user experience. We know, because we’ve gone through it in the past. You have to draw the line somewhere, and we drew it there.

If you want those casks to be versioned, you’ll need to ask the developers to either provide versioned downloads or appcasts.

@lock lock bot locked as resolved 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