Sparkle 1.23.0 caching AutoUpdate executable?

[DamienSirkis]

I may be grossly misunderstanding the way this actually works. If so, forgive me.

I'm currently in the middle of migrating my sparkle:version number from a single digit (say 600) to the actual app version number, say 2.1.34. I could explain the reasons for this change in more details but my question is regarding the behavior I'm observing while putting this together.

Because this move is seen like a downgrade by Sparkle, I decided to use a transition build of my app which contains a version of Sparkle that allows downgrades. Using the "version(build number)" notation here, people who have 2.1.33(500) can't downgrade but they are directed to 2.1.34(600) which contains a build of Sparkle that allows downgrades. That build will then find build 2.1.35(2.1.35) and should allow the perceived downgrade. Once the user has 2.1.35(2.1.35), downgrades are not allowed again and the next build will be 2.1.36(2.1.36).

The problem is, this doesn't seem to work reliably. I have situation when the 2.1.34 build refuses to downgrade and some machines when the same build updates to 2.1.35 without any problem.

My question is: Is the code that checks for the downgrade (I'm assuming its AutoUpdate) cached anywhere? I seem to be getting some builds of 2.1.34 allowing downgrades and some which do not. The code is the same and the Sparkle framework is the same (and should allow downgrades). So where is this finding a test for downgrading in some cases and not others?

[kornelski]

I'm not sure what's going on here.

Sparkle isn't caching the autoupdate app. But Sparkle asks the system for location of its bundle. Maybe macOS is caching the Sparkle.framework or gives it a location of some already-opened instance?

If you're releasing a customized version of Sparkle, try changing its bundle ID. That should ensure it's treated as a unique library.

BTW, Sparkle supports having different build version used for comparison and nice version presented to users, so you could not change your numbering scheme, and just have build version and user-visible version separate.

[DamienSirkis]

I found the cache which is in ~/Library/my.app.bundle/org.sparkle-project.Sparkle. It keeps a copy of the AutoUpdate app there but what is odd is that it seems to be the version of the incoming update and not the version of the installed app.

If this is the case it would throw off my assumptions on how the migration needs to be done.

(Re: the user visible version number. That's the system I used previously but it's very hard to merge build numbers between different branches (I'm branching to version 3.0, let's bump the version number from 500 to 600 to leave some room for other 2.0 releases. How much room? Who knows). If the build number is actually a version number (using major.minor.rev.beta which Apple also supports) then it's easy to merge those and Sparkle seems to do the right thing when a beta (2.3.4.1) gets released as a full release (2.3.4) and offer the update).

[DamienSirkis]

Any confirmation on whether the UpdateApp usually comes from the downloaded update and not from the currently installed app?

[kornelski]

I think the intention was that Auto Update is from the old version of the host app, so that the Sparkle version that started the install is the same as the one that finishes it.

If you're seeing a new Auto Update that's a surprise to me. Maybe there's a bug?