Best practice for when a new release breaks your code?

I just spent more time than I should have before realizing that

is replaced with


Is it possible to find these kind of changes documented somewhere, so that i can search for the now outdated method and replace it with whatever is suggested?

In the end, how I fixed it was by eventually finding my setting under ‘Ray Visibility’ → ‘Camera’ and choosing ‘Copy Full Data Path’. It’s a great feature when needed, but rather time consuming when I only know my broken method, and not where to find it “graphically”. There’s got to be a better way!

There are release notes for every release, and if there are any python changes they will appear in the Python API section.

That said, every little change that gets made will not necessarily show up in the release notes so it’s a good practice to pay attention to the console and see if it’s giving you some important information, such as AttributeError: 'Object' has no attribute 'cycles_visibility'. From there, I would search differential for ‘cycles_visibility’ to see if there was a check-in that broke it. Doing so shows me that yes, the properties were moved to increase parity between renderers. Scrolling down I can see the code diff and all of the updated property locations:

static inline uint object_ray_visibility(BL::Object &b_ob)
  uint flag = 0;

  flag |= b_ob.visible_camera() ? PATH_RAY_CAMERA : 0;
  flag |= b_ob.visible_diffuse() ? PATH_RAY_DIFFUSE : 0;
  flag |= b_ob.visible_glossy() ? PATH_RAY_GLOSSY : 0;
  flag |= b_ob.visible_transmission() ? PATH_RAY_TRANSMIT : 0;
  flag |= b_ob.visible_shadow() ? PATH_RAY_SHADOW : 0;
  flag |= b_ob.visible_volume_scatter() ? PATH_RAY_VOLUME_SCATTER : 0;

  return flag;
1 Like

That seems like exactly what I need, thanks!
It was through console I knew what crashed it (no attribute ‘cycles_visibility’) but thereafter I was lost.

How do you search diffferential? Your link provides exactly the answer I needed in this case, but would you mind explaining how/where you searched for ‘cycles_visibility’ to find this commit?

In differential, there’s a search box in the upper right hand corner. For your purposes you really only want to search for closed tasks, because if it’s something that has made it all the way through development into an official build it’s almost certainly not going to be an open task.

From here it’s mostly about finding what is relevant. For something like a breaking python change it will usually be something pretty obvious- you can see here that there are several addon-related breakages, in addition to the one that we actually care about.

Unfortunately there’s no way to sort search results by date, so every now and then you’ll get a result that is just completely irrelevant- so keep an eye on the posted date. The second search result is from 2012, for example.

1 Like

You can also grep the scripts that come with Blender for proper use. This does not always works since your code might be using some properties that the distributed ones do not. It is still a good practice.

most script and addons only need a line or 2 updated slightly

Not necessarily, sometimes there are breaking changes.