enhance Quicksilver version checking

[skurfer]

implement minHostVersion and maxHostVersion

As discussed on the list.

I’ve already put a version of the Cube interface out that advertises its lack of support beyond 1.1.3. It’s a little messy, since the update system prevents you from seeing that update if you’re already on 1.2.0. But those people have surely discovered by now that the Cube crashes QS. People still on 1.1.3 should get the update.

We need to make a small tweak on the remote side for the update system. When it’s returning a list of plug-ins that support the current version, it will still list the plug-in if maxHostVersion is the current version + 1. So maxHostVersion is acting like “minimum unsupported version” instead of “maximum supported version”. I think. Basically, I had to add 1 to what was in the database (16391 → 16392) to get the right behavior. :-)

[pjrobertson]

Oh dammit, I just accidentally deleted your comment, but I copied it in the meantime...

@skurfer said earlier:

I changed line 56 of plugin.class.php from maxHostVersion > \"$value\" to maxHostVersion >= \"$value\". Let me know if you think that’s wrong.

Thinking about it, that seems right. By the same logic, shouldn't maxSystemVersion (3 lines after) be the same as well then?

I didn't see the need for us to include this in v1.2, but I guess you're going along the lines that the Cube interface might one day be fixed, so we shouldn't obsolete it (although, it it is fixed we can just change the plugin ID)
How about that?

[skurfer]

Well, I was thinking Cube should remain available for download, but I guess obsoleting it won’t prevent that in older builds. Seems a bit harsh, though. 😃

By the same logic, shouldn't maxSystemVersion (3 lines after) be the same as well then?

I think that’s a little different. In that case, the setting the “user” (plug-in developer) sees is osUnsupported, which means “this or higher is not supported”. With the Quicksilver build we’re saying “supported up to this number”.

Yes, that’s inconsistent, but I think there was a reason. Maybe because we control QS releases, but not OS releases? I’d have to look back at when I added the OS checks, but no time right now.

[pjrobertson]

Looks good, just for my small (and no doubt annoying!) comment

[pjrobertson]

I said:

Does this mean we should now be documenting the use of minHostVersion instead of version (Obsolete that one?)

Apologies, I've just looked at the dev ref and you've done this. Maybe the reference to version should be mentioned as obsolete (as long as the server deals with minHostVersion)
NOTE: I've just noticed you say version and minSystemVersion. That should be minHostVersion (and maxHostVersion)

I think that’s a little different. In that case, the setting the “user” (plug-in developer) sees is osUnsupported, which means “this or higher is not supported”. With the Quicksilver build we’re saying “supported up to this number”.

Aaah OK I see, in that case you're right :)

Edit: I can confirm the server first checks the requirements dict for minHostVersion, then for version if that's missing.

[skurfer]

I think I remember why OS is different. Say 10.7.0 is released when 10.6.5 is the latest. We find that something is broken on 10.7.0. We can’t just say “support up to 10.6.5” because then 10.6.6 - 10.6.8 come along and cause the plug-in to be disabled, when it really doesn’t need to be. So instead we say “don’t support 10.7.0 or later”, which is what we actually mean.

[pjrobertson]

Ugh. Probably. :-)

I wasn't sure if that meant you were going to add it to this pull or not? :P

[pjrobertson]

I've updated the plugin dev ref: 85767be

[skurfer]

I wasn't sure if that meant you were going to add it to this pull or not?

Yeah, I plan to. Thought it would be done shortly after the comment, or I would have been more clear. Sorry.

I've updated the plugin dev ref

Thanks!

[pjrobertson]

Isn't documenting something always the best way to figure it out?

Well I've gone and documented/#defined the keys. Man that's a mess. I have no idea why the frameworks dict requires another resource dict inside it, and why there's no version key for the framework etc. etc., but I've documented the whole bang.

[pjrobertson]

So now it just needs you to merge before the next release ;-)

[skurfer]

Thanks. Sorry for the delay. Work has been ridiculous lately.