I wanted to check in with the developers about what blenders rules are for API stability. I see a SemVer like version number given to blender versions / addons but I’m also accustomed as a casual user to addons breaking between releases.
Any clarification on this issue would be really appreciated.
Blender does not use semantic versioning.
We try to limit major API breaking changes to major new versions like 2.80 or 2.90. But in every release in between there are also smaller API breaking changes, related to Blender features that are being added or improved in that release.
For bugfix releases and in particular LTS releases, the API is stable.
thanks @brecht thats the information I needed.
would you guys ever consider something like SemVer for the API? It makes it very easy to know when breaks have happened, I’d imagine it would improve the quality of life for Addon Development / Deployment. I’m not asking for a change in workflow, just a clear messaging of when breaks happen.
I’m not sure what that would do exactly. Would it just be another version number that is increased once every release? Or do you want to track daily changes in master?
Semantic versioning makes sense for software libraries, but for end user software it’s much harder to define. For example we might reorganize a menu, or improve the behavior of a mesh modelling tool. Usually that won’t break an add-on, but it can. These types of changes happen almost daily in master.
from the perspective of a Pipeline TD the API is a essentially a library. But I see where your coming from.
All I’d really ask for is that new methods introduced a minor version, removals or signature changes were majors and all bug fixes provided a patch. That way addon devs could specify a version range their addon should work for (think rez), then for inclusion in a blender release addons would need to be updated on breaks, or omitted for that version.
That’s coming from a very conservatively viewed developer who’s used to an unexpected API break costing 10’s of thousands of dollars in lost productivity, perhaps that doesn’t fit whats best for blender.
(Considering we now have the LTS this doesn’t seem as important.)
also I’m aware that what’s good for me might not be good for you.
Right, it’s just that there exist no minor versions for Blender, as defined by semver. There are major and patch versions, and nothing in between.
So you could define a semver number e.g. like this.
2.83.0 -> 77.0.0
2.83.1 -> 77.0.1
2.83.2 -> 77.0.2
2.90.0 -> 78.0.0
2.91.0 -> 79.0.0
But to me it seems that might add more confusion than it helps.
Yeah I take your point, not to mention that Artists tend to be emotionally attached to version numbers so it wouldn’t be easy to move the main release cycle to SemVer.
Honestly so long as LTS releases are API stable between patch versions that seems perfectly reasonable. Any Major release comes with the expectation that testing is required.
Thanks for your time @brecht I appreciate it.
Also I spotted a Suzanne during at a Arnold meeting a while back :D. That gave me a chuckle.