>From your mail it looks like all changes you note were from bmesh upgrade (except build_revision)
On Tue, May 28, 2013 at 9:36 PM, Domino Marama <dom...@dominodesigns.info> wrote: > On 05/28/2013 11:26 AM, Campbell Barton wrote: >> I still am a bit concerned that we get many complaints but very little >> real evidence of the cause of addon breakage - just that it happens, I >> realize not every project is opensource but enough are that links to >> scripts that break would be very helpful for API devs. > > For my scripts the changes to UV handling caused the most problems.. > Supporting multiple Blender versions from same script version results in > code like this: > > u_points = [] > v_points = [] > mesh = obj.data > > if svn <= 44243: > for f in mesh.uv_textures[uv_name].data: > for u, v in f.uv: > u_points.append(u) > v_points.append(v) > else: > if svn > 45996: > uv_loops = mesh.uv_layers[uv_name].data > else: > loopindex = mesh.uv_textures.keys().index(uv_name) > uv_loops = mesh.uv_layers[loopindex].data > u_points = [v.uv.x for v in uv_loops] > v_points = [v.uv.y for v in uv_loops] > > And other changes mean I have to do this to get the svn version :) > > try: > svn = bpy.app.build_revision.decode().split(':')[-1].rstrip('M') > except: > svn = bpy.app.build_revision.split(':')[-1].rstrip('M') > svn = int(svn) This isn't totally reliable, some builds dont include buildinfo, Id suggest using blender version rather then checking revisions. Also moving to git - revisions will work differently too. > I think the major problem is the changes such as these where the new way > replaces the old way. I test against SVN builds so usually catch changes > quickly and before my users do. But if I developed against release > versions, then a new RC is the first time I'd be aware of issues. If I > was on holiday, then it could even get to a release version and more > users hitting problems before I got chance to do anything. Without a > release or two with depreciated APIs it's something I need to constantly > watch out and allow time for. Its tricky and theres no perfect solution, suggest extension devs test their addons with our beta/rc's. > Things have been better the past few versions though. I've not needed to > add any more svn checks since 2.65 - currently in this particular addon, > there's over 20 checks to adjust for API changes but it does work on > 2.59 to 2.67. For each version from 2.59 to 2.65 there is at least one > check for the specific svn version to tweak things. > > While the majority of the changes are due to API improvements, sometimes > they seem to be changes that maybe should have been reconsidered. One > bit of my code walks over the edges of faces, so the only change needed was: > > if svn <= 44243: > faces = mesh.faces > else: > faces = mesh.polygons Keeping the attrubute ".faces" would have worked in trivial cases - change material for example. But would give more confusion in most cases since faces and polygons are quite different. > I am overdue for a code cleanup though. My official stance is that I > support 3 older versions of Blender, so the majority of the svn checks > are due for removal. For my first example, that results in the much nicer: > > mesh = obj.data > uv_loops = mesh.uv_layers[uv_name].data > u_points = [v.uv.x for v in uv_loops] > v_points = [v.uv.y for v in uv_loops] > > So although the API breakage is a hassle, I do see the long term benefit > to the changes. As said before, these changes are tied to bmesh, long term benefit is bmesh being much nicer mesh api. > It's my choice to support multiple Blender versions rather than > constantly recommending Blender updates as I get fewer requests for > support that way :) > > Hope that helps clarify the issues API changes create and how I manage them. It does but also confirms that BMesh was main offender (not sure you were aware of this regarding UVs?). > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers