>Erland doesn't like this, as it renders the check obsolete. Thus I  
>explained how it should be done. Which you don't like. But you've got the  
>choice.
>
I went for choice 3: I modified PluginManager.pm to ignore MaxVersion checks :-)

All 35 of my plugins remained working from 7.0 -> 7.1 -> 7.2, although one 
plugin currently doesn't work in 7.2 because of recent changes.  For people who 
run from SVN or nightly releases, the MaxVersion check even if done properly 
isn't going to be full-proof anyway.

>> plugin authors generally have no idea if a plugin will work in future
>
>They don't have to know the future. I said they should test and update. No  
>guessing needed, just a bit of work :-/.

It affects users in a big way, as with each new release no plugins will work 
until the authors (some of which have moved on) have modified a number in the 
MaxVersion and released a new version.  The user has to find, download and 
install each of their plugins again.

I have 35 plugins.  I don't particularly want to hunt around for 35 new plugin 
versions each time I go up a minor revision!

Do you think that plugin developers should always release plugins with 
MaxVersion set to represent the version it was last tested against, or is it 
okay for developers to release plugins with MaxVersion=*?

Phil
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/plugins

Reply via email to