plugin versioning

[Philip Meyer]

Having switched to 7.1/trunk, I found that no third-party plugins load, due to the max version checking.

I was suprised, because most of them have "<maxVersion>7.0+</maxVersion>" in the install.xml. I thought that meant that there was effectively no restriction. Do I remove the <maxVersion> node if there is no reason to have a max version restriction instead?

Phil

[mherger]

> Having switched to 7.1/trunk, I found that no third-party plugins load, due to the max version checking.

This issue should have been fixed a few days ago (and there's been quite some talk about it). Are you on the latest version?

--

Michael

[andyg]

On Apr 3, 2008, at 4:07 AM, Michael Herger wrote:
>> Having switched to 7.1/trunk, I found that no third-party plugins
>> load, due to the max version checking.
>
> This issue should have been fixed a few days ago (and there's been
> quite some talk about it). Are you on the latest version?

Actually I didn't fix the bug in the version parser that made '7.0+'
not work as you'd expect. I just replaced all our maxVersion values
with '*', which does work and is effectively the same thing. If
someone wants to tackle the version parser bug feel free.

[Philip Meyer]

>This issue should have been fixed a few days ago (and there's been quite some talk about it). Are you on the latest version?
I have latest SVN. I picked up a change for all internal plugins, when maxVersion is now set to *. But third-party plugins with maxVersion=7.0+ still don't load.

Phil

[max.spicer]

>This issue should have been fixed a few days ago (and there's been quite some talk about it). Are you on the latest version?
I have latest SVN. I picked up a change for all internal plugins, when maxVersion is now set to *. But third-party plugins with maxVersion=7.0+ still don't load.

They won't. You need to change the 7.0+ to * or 7.1+. 7.0+ only catches 7.0 releases. It sounds like the desired behaviour was for it to mean > 7.0. I guess that would actually be 7+.

Max

[erland]

How far can I increase maxVersion without risking that the plugin won't work due to changes in the plugin API or other behaviour ?

I assume that I can trust that if I've tested my plugin towards 7.0.0 it will probably work with all 7.0.x releases ?
What about 7.1 if I've tested it against 7.0.0 ?
What about 7.5 if I've tested it against 7.0.0 ?

I assume that I at least shouldn't set the maxVersion so the plugin is allowed to run in 8.0 because there is a risk that the plugin API will change between 7.x and 8.0.

[peterw]

They won't. You need to change the 7.0+ to * or 7.1+. 7.0+ only catches 7.0 releases. It sounds like the desired behaviour was for it to mean > 7.0. I guess that would actually be 7+.

Max

Would "7.+" catch any 7.x release (7.0.1, 7.1, 7.5, etc)?

Thanks.

[Philip Meyer]

I don't really get the purpose of allowing wildcards in <minVersion> and/or <maxVersion>.

A plugin developer must know what the minimum supported version is, so that can always be fixed, or not present if it works in any version of SlimServer/SqueezeCenter (I assume the plugin developer should set minVersion to the lowest version number that he's tested it with).

Similarly for maxVersion. If it works with the latest version, it can be assumed to work with any future version. If it is known that it will not work after a certain version, set the specific version that it will support.

Most third-party plugins seem to have maxVersion set to 7.0+, which appears to mean anything less than 7.1.

Should 7+ mean any version approaching 8.0.0?

At the moment, if users upgrade to 7.1 (which I assume would have minor impact on plugins) they will be frustrated that no third-party plugins will work until new versions are downloaded and installed. There was talk in the past of writing an auto-plugin download manager; that would help with the issue ;-)

It appears that a plugin will not load if maxVersion node is missing, so I guess <maxVersion>*</maxVersion> is the only way to say any version greater than min version?

Phil

[andyg]

On Apr 4, 2008, at 7:28 PM, Phil Meyer wrote:
> I don't really get the purpose of allowing wildcards in <minVersion>
> and/or <maxVersion>.
>
> A plugin developer must know what the minimum supported version is,
> so that can always be fixed, or not present if it works in any
> version of SlimServer/SqueezeCenter (I assume the plugin developer
> should set minVersion to the lowest version number that he's tested
> it with).
>
> Similarly for maxVersion. If it works with the latest version, it
> can be assumed to work with any future version. If it is known that
> it will not work after a certain version, set the specific version
> that it will support.
>
> Most third-party plugins seem to have maxVersion set to 7.0+, which
> appears to mean anything less than 7.1.
>
> Should 7+ mean any version approaching 8.0.0?
>
> At the moment, if users upgrade to 7.1 (which I assume would have
> minor impact on plugins) they will be frustrated that no third-party
> plugins will work until new versions are downloaded and installed.
> There was talk in the past of writing an auto-plugin download
> manager; that would help with the issue ;-)
>
> It appears that a plugin will not load if maxVersion node is
> missing, so I guess <maxVersion>*</maxVersion> is the only way to
> say any version greater than min version?

IMO, maxVersion is a useless field. How can you possibly know at what
point your plugin won't work with some hypothetical future version?

[Philip Meyer]

>IMO, maxVersion is a useless field. How can you possibly know at what
>point your plugin won't work with some hypothetical future version?

maxVersion is useful for limiting the use of the older plugin. At the time of writing a plugin, a developer won't know that the version supporting 6.5 won't work in future versions, but at a later date, may update the plugin to limit it from running on later releases.

A plugin developer may then release two versions of their plugin; eg. one for v6.5 of slimserver, and one for v7.0 of SqueezeCenter.

But allowing wildcards for maxVersion is meaningless/useless.

Phil