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

Campbell Barton ideasman42 at gmail.com
Sat Aug 17 21:21:00 CEST 2019

The API’s in Blender have different levels of maturity, 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's 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.
Well after we agreed not to make breaking changes to 2.80 API these
kinds of *technical* breakages were being made (converting booleans to
enums for example to change how buttons display).

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 changes to the
internals often change the underlying RNA/operators.


Since we already try not to break fundamental parts of the API's in
point releases, all of this may just be formalizing what we're already
doing - communicating it to add-on developers.

If this is more about communication, instead of adding the overhead of
maintaining detailed information about exactly what parts are/aren't
stable, we could have a more general documentation about areas of the
API we consider stable for the 2.8x series.

On Thu, Aug 15, 2019 at 11:27 PM Brian Savery <brian.savery at gmail.com> wrote:
> 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!
> Brian
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

- Campbell

More information about the Bf-committers mailing list