[Bf-committers] Release cycle 2.81: dates and branch proposal

[Brian Savery]

>
> 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....


>
> --
brian.savery at gmail.com
508-274-8700