Blender 2.81 and api compatibility

Cross posting from bf-committers for visibility and discussion:

First of all, Kudos for the 2.80 release, and I think the move to higher frequency smaller releases with 2.81 is great.

One thing that I have not seen discussed with this release cycle change is the python api and addons.

Currently, as things stand, a user would have to reinstall all addons with each new release between 2.80 and 2.81, which is fine with older release cadence, but becomes slightly more burdensome with quarterly-ish releases.

Furthermore, what about api compatibility and python compatibility between releases? Has there been a discussion about that? As an addon developer, I feel the 2.80 release was a bit late breaking some apis (especially for render engines) and would prefer not to see that repeated with each 2.XX release. Us addon developers would prefer to no have to put out a version for each quarterly release if possible (but this might be selfish a bit on our part).

This is all further complicated if an addon uses c extensions that need to be compiled against a certain python version, and that python version changes between Blender versions. Overall, this might be one more vote towards moving to a version scheme like 2.8.1 where api and python version is stable across minor versions.

Anyway like I said I haven’t seen this point brought up. If there’s a discussion somewhere I could contribute to, please point me there!

1 Like

Personally, I find that there are many ‘holes’ in the python API right now that could be improved, so if I were told that there would be no improvements to the Python API except once every year or two I would be fairly frustrated by that.

Now, if we were to adopt a non-backward-compatible update policy, where new things could be added but ‘current’ API calls wouldn’t be deprecated until the next major release I would be all for that. If you’re familiar with Unity’s C# library, this is basically how they do it- they add new functionality all the time and if they decide that something needs to go it gets flagged as deprecated. Any time you use that functionality you’ll get a compiler warning letting you know that it will go away in a future version so you can keep it on your roadmap or fix it right then and there if you want.

The only ‘downside’ with this is that point releases aren’t usually going to be backward compatible. So, if new python api calls got added for 2.81, those scripts wouldn’t work in 2.80 but they would work on 2.82, 2.83, etc. When 2.90 comes out, all of the 2.8x deprecated calls are removed and addon developers who have not kept up will have to refactor. At least this way you can do some planning on when and how you update your addons rather than being forced into it for every point release.


Hi @bsavery,

I already replied on bf-committers here. Thanks for your input! Same goes for @testure, appreciated :slight_smile:

As I mentioned on the ML I hadn’t really given much thought to it, but I understand the burden the pace of breaking changes is tough to keep up with.

I’d like to see us do a better controlled approach to our API development, taking the add-on eco-system at large into account better.

As @testure I’d say that adding new API should be always possible, even between subsequent ‘minor’ releases, but a better scheduled (read: longer adjustment period) deprecation scheme along with improved warnings for add-on devs would in my opinion we should try to accomplish.

I hope we can discuss this further also during the upcoming dev meeting.

We’ll need some concrete proposal from the Python team that addresses your points as well as it can. It’d be nice if @ideasman42, @mont29, @BrendonMurphy, @jacqueslucke, @sybren et al to put their heads together and see if they could whip up something in the coming few weeks. Please? :slight_smile:

1 Like

First if all, there are different API’s in Blender with different levels of testing, some are stable and it’s unlikely we would break them. Others - such as GPU drawing or tool/gizmo API’s, have not been tested enough, so it might not be in our best interest to try stabilize them before we validate they work well.

Given Blender has quite a few API’s, saying “lets not break the API” isn’t a useful statement.

Especially since virtually any change to RNA/Operators could be considered a breakage.

We could have support levels, marking areas of the API:

  • Stable, where breakages are considered bugs/errors, we avoid unless it’s absolutely necessary (an important bug-fix relies on modified behavior for example).
  • Unstable, where the API hasn’t been well tested and changes may be needed in the future.

The remaining parts of the API will be quite stable - in practice, however we can’t guarantee they wont change, since new features in Blender often change the underlying RNA/operators.

It’s the usual situation of having to break some eggs to make an omelette. You cannot such a well designed API if you don’t break it in every release.

The irony here is that we talking Python, the biggest breaking compatibility scandal in the software of coding that I am aware of. Unfortunately no matter how wise one is rewrite code is the only move forward. It’s annoying sure but the example of APIs that refused to rewrite code and keep backward compatibility no matter what and now none wants to touch with a ten foot pole is too many to even count.

Breaking BPY is not even knew thing it has be happening for the last 14 years I have been around.

Couple things here: Sorry using common language idioms to relate to software development is one of my pet peeves. But if you’re making an omelette like you say, and keep breaking more eggs, in the end you’ll be left with a really messy egg soup :wink:

I would actually argue the opposite. If the api was really well designed it should not need to be continually broken!

I won’t claim to know the whole BPY system as well as @ideasman42 but with regards to ones we used for the render engine there was quite a bit of change with 2.80. Unfortunately a lot of these changes came fast and late, which make it hard for addon developers. (Look at how many released non-beta rendering addons are out now… very few)

If we move to a quarterly release with similar changes and addon developers are always playing catchup, a robust addon community is going to be tough. I’m not saying things should never change, but some system for depreciation might smooth it out.

Furthermore, if the intention is to get Blender into studio film systems, that’s going to be quite hard with this rate of change. These guys are still using Python2 in most places (!).

And as a last note, @kilon I’m not sure what you’re referring to with Python’s “Breaking compatibility” scandal? Are you talking about Python 2 to 3? Actually Python is pretty good here. Python 3.X.Y scripts are compatible over all “X” versions, and as far as I know, any script written for Python 3.2 will work with Python 3.7 (the aforementioned c-extensions not withstanding). If anything Python 2 to 3 suffered from not moving fast enough encouraging people to move to 3.

@bsavery could you reply in blender-committers mailing list, since this post has more activity there.

sorry about late reply but i was on vacations

Yes I am talking about 2 to 3, even Guido (creator of Python) admitted the way they handled the transition was not ideal and the whole thing was a mistake. Python 3 is not by far the dominant force, but took a long time for projects to migrates. Personally I think the mistake was that they broke too many things and really fundamental things that could not be avoided. On the other hand everyone agrees that overall it was a good choice from the perspective of improving the language. If changes were gradual I think people would have followed along instead we got tons of libraries stuck in Python 2 for so long. Fortunately Python 3 nowadays is almost completely embraced by the community.

Of course with Blender is diffirent because Blender is not a general purpose programming language, but a specialist tool which brings very important improvements in every version so keeping up with the latest version is far more important than keeping up with the latest version of Python.