Set minimum application version for update

[jhogrefe]

I have an application that originally had an update folder location for minor version 1 releases called "update". When I moved to version 2, I now have a folder location for minor releases of version 2 called "update2". My problem lies in the fact I accidentally released a version 2 minor version that pointed to the original "update" folder, not the "update2" folder. Is there any way to add something to the Appcast file that specifies version number of the application so I can place it in the original "update" folder allowing version 2 users to update to the newest version, but not allow version 1 users to receive this new update?

[kornelski]

That's an interesting idea. I've ran into similar problem when I've pushed out a bad update.

Perhaps that would even be a minimal solution for sending beta updates to beta users: https://github.com/pornel/Sparkle-fork/issues/20

[lostminds]

Hello, it's been a couple of years, but I'd like to revive this proposal, or something like it. Basically adding another (optional) parameter to the appcast format, similar to sparkle:minimumSystemVersion, but perhaps sparkle:minimumApplicationVersion that will mean that sparkle will only offer the update to users with application above a certain version. This could be useful in a couple of additional cases:

• If you for some reason need to have people upgrade in several steps (from 1.x to 2.x, then 2.x to 3.x)
• Or, where you have users using an old version 1.x that you want to upgrade to the latest 1.x version and then when they have the last 1.x version you want to offer them 2.x which is a paid upgrade that they may or may not want.

[johndbritton]

If you for some reason need to have people upgrade in several steps (from 1.x to 2.x, then 2.x to 3.x)

I need to change my update signing keys and would like to use a feature like this to make sure that any user on version <1.1.0 first updates to 1.1.0 before being able to download updates greater than 1.2.0. This way I can release version 1.1.0 with a signature that will be valid to older versions of my application and any releases after 1.2.0 can be signed with a new signing key.

[kornelski]

There's a related feature: #1688

[kornelski]

For now the only way is to change appcast URL, so that old apps see only the old appcast, and new apps can be given a different appcast.

[johndbritton]

For now the only way is to change appcast URL, so that old apps see only the old appcast, and new apps can be given a different appcast.

Oh this is perfect, thanks.

[lostminds]

There's a related feature: #1688

That looks great, but I still think it would be great if there was a similar "sparkle:minimumVersion" parameter just like the "sparkle:minimumAutoupdateVersion" now implemented. For me the case is the same, that I want to add an item for a paid upgrade (say 7.9.0 to 8.0.0) in the app cast to notify all users about the available upgrade. However, I also want users of older versions (like 7.x.x) first update to the latest 7.9.0 version before the paid upgrade to make sure they get access to the latest version they've paid for.

What I do now is I have a dynamic php generated appcast that at random sometimes offers the last 7.x version and sometimes the 8.x for users of v7, so that they will at least with time get both prompts. But it would be some much more elegant and less of a hack to have a property that offered 7.9.0 if their version was < 7.9.0 and offered 8.x.x only if version >= 7.9.0

[zorgiepoo]

I don't think a new attribute is necessary to fix the paid upgrade case.

1. Filter out appcast items that don't pass min/max OS and phased group rollout (edit: and skipped updates).
2. Find the latest appcast item that passes sparkle:minimumAutoupdateVersion. If there's a new one available, use it.
3. Otherwise, find the latest appcast item that doesn't pass sparkle:minimumAutoupdateVersion. If there's one, use it.

The appcast selection code in 2.x branch is more correct regarding filtering and easier to extend, although there's still various features fighting against each other here..

I think the skipped update feature for automatic checks will also need to change to skip a specific set of versions, not skip everything equal and below a specific version as it currently is.

[lostminds]

Yeah, for me it would be ok if there was just a way to use the sparkle:minimumAutoupdateVersion if that could be applied to regular update checks as well. Only if that was the case the name might be misleading as it would no longer be an Autoupdate-only parameter.

Regarding the skipped updates I've suspected something might be going wrong there, and your comment there really explained that. So, in my case I'm offering users of 7.x both the latest update to 7.x and using the appcast to announce that there's a paid 8.x upgrade. If what you say is true, clicking to skip the 8.x upgrade will then mean they will never get offered any further 7.x updates? I guess that could explain why a lot of old version users have stopped updating, even though there are available free updates for them.

[zorgiepoo]

Yeah, for me it would be ok if there was just a way to use the sparkle:minimumAutoupdateVersion if that could be applied to regular update checks as well. Only if that was the case the name might be misleading as it would no longer be an Autoupdate-only parameter.

Yeah but it makes sense to extend this, it's clearly for dealing with paid upgrades and a developer would still like to notify users of when paid updates are available (just not automatically install them!)

If what you say is true, clicking to skip the 8.x upgrade will then mean they will never get offered any further 7.x updates?

Sort of yes, but also in your favor, if they skip 8.0 and you release 8.1, the 8.1 one isn't skipped. If they get an update alert for 8.1, the choice of skipping 8.0 also gets reset. But if they then decide to skip 8.1 they won't see 7.x. If they don't skip 8.1, they'll see 7.x again.

The skipping logic here is actually more complicated than I thought:

If a user is on 1.7 and 2.0 is a paid upgrade (with sparkle:minimumAutoupdateVersion set to 2.0), you want to notify an update is available but not automatically install/download it.
If they skip "2.0", and 2.1 is released, they want to implicitly also skip 2.1 (with sparkle:minimumAutoupdateVersion also set to 2.0)
If they skip "2.0", and 3.1 is released as another paid upgrade (with sparkle:minimumAutoupdateVersion set to 3.0), you may want to notify a major new update is available but not automatically install/download again.
If they skip "2.0" and both 1.8 and 1.9 is released (with no sparkle:minimumAutoupdateVersion), you want to notify them 1.9 is available.
If user is on 1.7 and they skipped "2.0" and skipped "1.9", they want to implicitly skip 1.8 too.
If user is on 1.7 and they skipped "3.1" (with sparkle:minimumAutoupdateVersion set to 3.0), you may want to notify them "2.9" is available (with sparkle:minimumAutoupdateVersion set to 2.0), maybe(?). Rare scenario.

So, I think, if you skip an update, you need to keep track of the sparkle:minimumAutoupdateVersion skipped too. If you don't pass the minimumAutoupdateVersion, you skip all versions that have that same sparkle:minimumAutoupdateVersion. If you do pass it, you skip versions <= than the one you had skipped. And the skipped versions still needs to be set of versions and minimumAutoupdateVersion's.

If the user manually checks for updates, all skip choices are reset.
If the user is automatically notified of a new eligible update, we still need to preserve skipped updates.

Darn it's complex and hopefully I'm not missing a case.

[lostminds]

Optionally you could consider the "skip update" simpler and just be specific to the version skipped. In other words clicking "skip this version" would just save this specific version to an array of versions to not present to the user.

That way if an available version > current version would be presented next check, as long as it hasn't been specifically skipped. The user can get the choice to not get a specified update, but won't at the same time (unknowingly) say no to other updates they may not know about. If a user has a very old version, it might result in a lot of offers to update as skipping one will then offer the previous update next check, but that's not a bad thing in my mind and they can still skip those too (or just disable automatic checks).

If the skip choices all get reset if you manually check for updates that's great news (if that's how it works now). Then at least if users check for updates they'll be able to get access to my older updates eventually.

[zorgiepoo]

That way if an available version > current version would be presented next check, as long as it hasn't been specifically skipped. The user can get the choice to not get a specified update, but won't at the same time (unknowingly) say no to other updates they may not know about. If a user has a very old version, it might result in a lot of offers to update as skipping one will then offer the previous update next check, but that's not a bad thing in my mind and they can still skip those too (or just disable automatic checks).

I don't believe this leads to a good user experience and would be a regression from the current code intending to skip versions downwards. One could better argue that updates to next paid version shouldn't be skipped upwards, but as a user I am still thinking that should be the case, and I think that is what ends up happening when developers used a different appcast for their next paid version.

If the skip choices all get reset if you manually check for updates that's great news (if that's how it works now). Then at least if users check for updates they'll be able to get access to my older updates eventually.

Yes, half the story. They also can't skip any future updates if you post them to the same appcast. When they are presented with a new update, the skip choices are also currently reset.

I think we should avoid prompting the user unnecessarily to the point they will want to disable automatic update checks.

If they don't skip an update, nothing really changes; could also be overestimating skip usage here.

[lostminds]

Yeah, maybe you're right I guess it depends on if you interpret "Skip" as "Skip this specific version" or "Wait until the next newer version".

Perhaps another way of approaching/solving the problem could be to allow some sort of "news"-update items for the purpose of marketing upgrades like this. Items that notify the user of a new paid upgrade being available but without any sparkle download (just a link). Instead of a skip button Sparkle would just keep track of having shown this news-update to the user (so they don't get notified again next auto check), so it doesn't consider this a version the user has skipped.

[zorgiepoo]

We have informational updates if you provide a <link> and don't provide an enclosure url, in which we have a learn more button that opens a webpage in user's web browser. Developers use this when their updates get hosed, and maybe for paid updates where they change their appcast in their next major version.

But they get scheduled like our other updates and can be skipped (I don't think they should implicitly be skipped). I don't think this really changes anything. You still want to post new updates pre major release, and post major release and want users to be notified or be able to skip them appropriately.

I think working with sparkle:minimumAutoupdateVersion and the existing system is the way to go.. Also to reduce the need of using multiple appcast feeds. The changes to pick best available version can be done separately from extending the skipped version functionality.

By the way for your current situation I believe Sparkle sends the short and bundle version as part of the user agent string, which gives you ability to detect their versions server side (albeit you may need to do some parsing).

[lostminds]

Yes, I use the items for the upgrade offers now, but since they cause the skip issue it's still a problem. I agree that being able to set some sort of minimumVersion per item would be best.

The user agent string was a great tip, and it seems like it works. Couldn't find anything describing this in the documentation, but when I examined the users agent string it looks like the default user agent string (at least in Sparkle 1.26) is PRODUCT/PRODUCT_VERSION Sparkle/SPARKLE_VERSION so it can be easily parsed. Thank you for that!

[zorgiepoo]

Made an issue regarding documenting user agent string. It looks like we just pass the display/short version string (I think).

I've been fixing up issues with the appcast selection code, maybe I will get to at least picking the most appropriate update at some point (behind other things I need to fix). And the skip logic at some later point.

There is another issue regarding picking the best item also regarding beta updates (#51), but I still think this is the way to go now.