[Qgis-developer] Version number in plugin path?

Carson Farmer carson.farmer at gmail.com
Tue Nov 11 07:46:56 EST 2008


All, (apologies to Martin, who has already received this email...)

 >> I see our discussion has died. But one thing is absolutely essential -
 >> introducing the qgisMinVersion() method (or apiVersion(), however I 
believe
 >> the former is just much clearer).
 >>     
 > Agreed. I'm going to implement support for qgisMinVersion method
 > (you're right, it's clearer) to distinguish which plugins can be
 > loaded safely.
 >> gsPythonUtilsImpl::loadPlugin should reject the incompatible 
plugins. Martin
 >> what do you think? Would you like to implement it? I don't know if 
is there
 >> any _good_ function for version comparision? (for Python I haven't 
found any
 >>
 >>     
 > sufficient so I had to write my own).QGIS versioning scheme is 
"x.y.z" where x,y,z are numbers, sometimes
 > 'z' can be omitted and is considered as zero. So I think there
 > shouldn't be a problem comparing the versions.
 >> ow I'm going to implement it in Installer. Uncompatible plugins in 
repository
 >> will be masked while installed uncompatible plugins will be marked red.
 >>     
 > This sounds like there's need to add minimal version tag also to
 > repository's XML.
Yup, something like:

<qgis_version>
 >= 1.0.0
</qgis_version>

or we could just assume this is the minimum and omit the >=
 >> o if nobody object, I'm introducing the following metadata:
 >> qgisMinVersion
 >> qgisMaxVersion
 >>
 >> They are of course optional. If missing, the plugin will be loaded 
anyway.
 >>     
 >
 > I prefer to be strict and require qgisMinVersion in every plugin.
 >   
This is how it has been in the past, if __init__ .py doesn't have
name(), description(), and version(), it won't be loaded... Also, since
current plugins won't be able to work with the new API without
significant changes anyway, asking plugin developers to add a new method
to their __init__.py files won't really be asking that much more ;-)
 > However I don't know whether we really need qgisMaxVersion as max.
 > version can't be usually predicted and I suppose that developers will
 > ignore it or put some arbitrary high version numbers.
I agree, max version will likely be unused/unnecessary...

C



More information about the Qgis-developer mailing list