Blender 4.0 Breaking Changes for Add-ons

Blender 4.0’s official release was pushed back to next week. But until then, let me go over it’s big changes as an add-on developer:

Why is 4.0 such a big change?

You can go to their Wiki for the full list of changes: wiki.blender.org/wiki/Reference/Release_Notes/4.0

But the biggest changes for Blender’s Python API (and subsequently, add-ons) include but are not limited to:

• Various mesh data attributes, such as bevels and creases, are renamed and/or moved.

• Principled BSDF node has been revamped, and its input sockets have been renamed and reordered.

• Node group data has changed radically. Previously, it had two separate lists for input and output sockets. Now, those have been merged into a single list of sockets. Each socket now stores whether it’s an input or output.

• Renaming multiple functions, including those in the gpu module to draw custom UI widgets.

• New UI conveniences, like accessing the property field underneath the mouse cursor, and displaying a progress bar in the UI. Really excited for these to be used!

This may seem like relatively small changes. But keep in mind that add-ons should have backwards compatibility. An add-on working for Blender 4.0 should behave the same in 3.x.

Case in Point: Shot Matcher

I recently updated one of my old add-ons, Shot Matcher, to support Blender 4.0. This add-on allows you to color grade images or videos to match the colors of another one.

In the compositor, it creates a node group, adds a color grading node inside, and connects it to the group input and output sockets. Simple enough, right?

Not anymore. As said above, input and output sockets are now stored as one list. My function to setup sockets in two lists would raise an error in 4.0. Since the 4.0 changes wouldn’t be backwards compatible with 3.6, I added a condition:

# if Blender version is >4.0, access single list of sockets;
# otherwise, access the input and output socket lists.

While it’s not ideal to have code conditional on the version of a library it’s using, sometimes it’s necessary. Once 4.0 has an official LTS, developers can safely assume most have moved on to 4.0, and remove the old code.

This is not best practice, as it makes the code dependent on the Blender version. But sometimes it’s necessary until a new LTS version has come out, and most users have upgraded to it. Then I can safely remove the 3.6 code.

In short…

Be patient with any add-on developers as you migrate to Blender 4.0. It’s changelog is big, especially for add-ons. And I only listed some of them! Be sure to report any bugs too; that’ll only speed up their process.

I’m currently doing checks for all my add-ons in the next couple weeks. Fingers crossed they’re simple fixes, if at all!