[Bf-committers] Python API breakage - squeaking wheels

[W. Nelson]

Would some sort of scheduling updates to a specific date or version of Blender help alleviate a lot of the finding out after the fact issues that seem to be floating to the top of this conversation?

That would give time for looking at the upcoming change before it gets committed.  It could be proactively posted on a scheduled changes to py wiki page.  If there is not urgency to the change, then it would come at predictable or expected time frames.  This allows us 3rd party script developers to be proactive instead of reactive to changes.  Predictability even gives core development clear windows of opportunity.


Something as universal to Blender as Python/scripting maybe could only be updated with specific version numbers or reduced to once or twice a year.
Without throwing fuel on the versioning topic in general...maybe something like second digit changes and the 5 on third digit changes.  

EG:  py maintenance updates only on 2.70, 2.75, 2.80, 2.85...

Or date changes could be used.  Only twice per year at most maybe?  

EG: February's nearest release after February 1st and July's nearest release after July 1st  


Maybe some variation on these ideas could be a good balance of progress and mitigating fails with predictability.

RECAP:
Proposing ideas like-
  flipping the reactionary coin to proactive side

  scheduling updates to py for predictability

  changes only on dates or specific version numbers  

  wiki page with upcoming changes

JTa




________________________________
 From: Domino Marama <domino at dominodesigns.info>
To: bf-blender developers <bf-committers at blender.org> 
Sent: Tuesday, May 28, 2013 9:17 AM
Subject: Re: [Bf-committers] Python API breakage - squeaking wheels
 

On 05/28/2013 02:31 PM, Campbell Barton wrote:
> >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
> <domino at dominodesigns.info> wrote:
>> 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.
Yeah I just posted that because of the irony in my routine for handling
API changes being affected by them. I'm sure you see the additional
irony in pointing out that it is going to break again in the future :)

In the full code the svn = int(svn) line is in a try: except with a
fallback of estimating a svn number from the Blender version. I had to
do it this way as the Blender version isn't updated until release so
when API breakages occur I need to be able to target specific commits to
test against current builds
> It does but also confirms that BMesh was main offender (not sure you
> were aware of this regarding UVs?).
>
Yeah the majority of the the current switches in my code are bmesh
related. I couldn't do a full switch to bmesh without losing backward
compatibility, so it's mostly old API with just the UV handling from
bmesh on newer versions. Now there's enough old versions with bmesh I
can plan the full migration of the code to the new APIs.

Prior to that the last big script shakeup was the switch to python3.

I really posted as an example of a different way that script authors may
be working. Assuming a new Blender release with API changes means that
script authors will do new versions of their scripts makes work for
people who may not have scheduled for it. Having a few releases where
depreciated functions give warnings lets people schedule these things in
rather than having to make it their main priority. For those of us who
support older versions on same scripts, it also makes life a little
easier as we could fall into synch with the depreciation cycle rather
than having to work around things to keep compatibility.
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
http://lists.blender.org/mailman/listinfo/bf-committers