SVN: 42503
The 'blender' and 'api' sections of an addons bl_info are currently ignored. This results in users trying to use scripts on versions of Blender that do not support them.
I've attached a patch which makes addon_utils.enable test these variables and abort if the addon is not supported by the current blender version.
There was also an error in the wiki description for the bl_info 'blender' variable which means most existing scripts have versions like (2, 5, 9) instead of (2, 59, 0) - I've corrected the wiki, but not the existing scripts. http://wiki.blender.org/index.php/Dev:2.5/Py/Scripts/Guidelines/Addons#Script_meta_informations
Description
Description
Event Timeline
Comment Actions
Actually, this patch doesnt solve all issues -- api can be easily "broken" in newer versions of blender. Also in some cases it's possible to run addon on older versions of blender (not sure how critical it's in current context).
Campbell, can you please check this patch?
Comment Actions
Hi, looked at the patch and think it should work a bit different.
- don't check api, this may be removed its not used afaik. also you can build blender without this info.
- allow scripts to load even when wrong version, better just do a warning print.
- warning message should also show in the addons UI so users without a terminal are not confused by whats going on.
Its too late to apply the patch now but would be ok to apply modified version after release.
Comment Actions
The reason I checked both, is that it seemed reasonable that only one of these would be set. Scripts that are targeted for release versions would use"blender" and ones that need an SVN build would use 'api'.
If 'api' is optional in a build, then there is no easy way to support multiple versions of Blender with scripts. I try to support at least a couple of versions in my scripts and check bpy.app.api where the way of doing things has changed. Eg, if the patch to change matrix math that is being discussed on bf-commiters is applied, I'd use 'api' as a check for when the patch is applied so I can support earlier and current builds with the same script.
If a new API feature is introduced then I'd use 'api' in 'bl_info' to set the minimum build required, once the next release comes then 'blender' in 'bl_info' could also be updated.
Comment Actions
The last 'api' in the second paragraph of my previous comment should be bpy.app.api :)
Rather than not implementing the 'api' in 'bl_info' because bpy.app.api may be broken in some builds, doesn't it make sense to provide a way to fix bpy.app.api - I know when I was using bzr for my local repository, that bpy.app.api wasn't set. So would be adding a command line option to cmake and scons to set an api value for cases like that be a better option?
The patch already allows for local modifications by stripping the "M" suffix from bpy.app.api - if theres other ways to break bpy.app.api I'm not aware of, would another option be to add bpy.app.api_number or something which is guaranted to be a testable integer?
Comment Actions
I've added a v2 patch with the requested changes, I hope you give some thought to my comments though as this is really only a partial solution to the issues.