solved Workflow updates don't show up in Gallery

[kometenstaub]

I've been using the Shimmering Obsidian workflow by @pseudometa for a few months, recently it was accepted into the Alfred Gallery.

 

The version it shows in the Gallery is 3.8.9, but the latest version is 3.9.1.

 

The latest update available in the app is 3.8.9 as well. To get the latest update, I updated it manually. However, in Alfred it still shows up as updatable, although the installed version is higher than the fetched one.

 

Unless there is something the author needs to do, might this be a caching issue, apart from the (missing?) version check?

 

Alfred version: 5.0.6

macOS version: 13.2.1

 

Attached are the screenshots that show the issue.

 

Version in Alfred Gallery:

 

 

Latest release:

 

Currently, manually installed version:

 

 

The workflow is shown as updatable:

 

 

Version that is fetched after clicking update:

 

 

 

 

 

Edited April 16, 2023 by kometenstaub

[vitor]

That update was released yesterday. By design, workflows updates are not reflected in the Gallery immediately. Among other things it allows for the short feedback loop where a workflow creator adds a requested feature, it’s tested and kinks are ironed out, then it’s released. This way we avoid more people getting the intermediary version and can serve the known good one.

 

In other words, everything is working as expected.

[pseudometa]

13 hours ago, vitor said:

By design, workflows updates are not reflected in the Gallery immediately. Among other things it allows for the short feedback loop where a workflow creator adds a requested feature, it’s tested and kinks are ironed out, then it’s released. This way we avoid more people getting the intermediary version and can serve the known good one.

 

I fully agree with that design decision (in fact, I have requested such a delay for other package managers as well.)

 

Nevertheless, I do think op has a point, insofar as an upgrade mechanic should never downgrade your software. In this particular case, it seems this downgrade could have even happened unknowingly if op did not pay attention to the version number. Unintended downgrades are definitely something I would consider a bug.

 

I think adding a simple a version check could already fix this issue?

[vitor]

If a user manually updates from outside the Gallery system, they’ll know they have done it and will have done so for a reason. The icon change will be immediate and they’ll know to ignore it for a day or two.

On the other hand picture the case where an update has a potentially problematic bug¹ and it must be rolled back². Updating to a previous version becomes desirable. If the update icon remains there for a while, that’s a signal for the user to check what happened.

Every approach has a tradeoff. Manually updating is bound to be more common³ than having to roll back, but if ever necessary the rolling back will be more important.

 

All that said, I hope it goes without saying that the feedback is welcome and we’ll refine and improve as necessary. Also note that as a creator you can ping me if there’s something urgent.

---

¹ There was once an update which introduced an rm command which did not quote the variable it removed, which could potentially delete what was unintended due to the shell splitting on spaces. I caught it before adding to the Gallery and reported it to the developer who fixed it fast.

² Technically it would be a version downgrade but a functional upgrade because it would fix the regression.

³ Though still relatively rare.