> > For example, we are adding and extending shader nodes in 2.81. For an > external renderer that supports our shader nodes, they'd want to > update their add-on for that.
Side note but can you point me at that documentation? Changes like this are expected in the spirit of moving forward with each minor version as long as the old node api isn’t broken. > > > We could restrict lower level API changes to a release every 6 or 12 > months. Things like the math libraries, add-on registration, operator > definition, depsgraph API, etc. That line is a fuzzy and hard to > communicate, but can help anyway. Even then, we may for example want > to do an important performance optimization that requires changing the > depsgraph API, and waiting a long time for that would not be ideal. > > For the 2.80 release, the API was stable for the last 2 months. For > this shorter release cycle, it would be about 1 month probably, but > the number of changes would be much smaller. > > For an end user application like Blender semver is not common as far > as I know, it's mainly for libraries. Moving to semver would > effectively mean 2.81 is 3.0, 2.82 is 4.0, and so on. That may or may > not be a good idea, but I think such a decision should primarily based > on communication to end user, not add-on developers. > That’s fair and if that’s the answer I think addon developers will adjust. But as you said the fuzzy line of 6-12 months for breaking changes is a bit fuzzy. One would hope that in that time old api is not removed but deprecated. And then it’s mainly a problem of communicating the “big releases” that break api And I do agree the major version should be about changes to the end user. By that argument though 2.80 would be 3.0 and 2.81 be 3.1.... > > -- [email protected] 508-274-8700 _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
