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

[Dalai Felinto]

Hi,

One thing related that I would love if we had, is a way to aggregate
the "what changed" docs for multiple releases.

Say an addon-developer wants to port an addon from 2.80 to 2.86. Now
instead of looking at 6 different pages he/she can go there, and look
at a list (split by release, or category) and get to work. This is
likely useful for users as well.

I think this particular needed in software that do release new builds
too often, and if want shorter continuous release cycle it would be
nice to handle that.

Not sure if anyone in the industry does that, but it would be nice to
see how others do it.

Regards,
Dalai
--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com

Em sáb, 17 de ago de 2019 às 09:27, Brecht Van Lommel
<brechtvanlommel at gmail.com> escreveu:
>
> Realistically, we can't guarantee the entire API to be stable. Any
> change to operators, user interface, modifiers, nodes or settings can
> affect add-ons. Not being able to make these types of changes would
> severely restrict which end user features can go in 2.81, that
> wouldn't work.
>
> 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. For sculpting we are changing tool
> settings to support new functionality, and any sculpting add-on can be
> affected by that.
>
> 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.
>
> On Fri, Aug 16, 2019 at 10:10 PM Nathan 'jesterKing' Letwory
> <nathan at blender.org> wrote:
> >
> > Hi Brian,
> >
> > Thank you for your input. The Python API and add-ons were indeed not
> > specifically mentioned.
> >
> > In the proposal I glossed over submodules, but the idea is to create
> > in each submodule corresponding 2.81 branches for stabilizing. That
> > will also ensure we can keep master and the release branches clearly
> > separated. That in itself is separate from the Python API issue.
> >
> > I think it would be good if we could come to a good policy of not breaking
> > the API between major releases - a bigger timespan than 3 months would
> > probably be beneficial for the add-on ecosystem, allowing add-on devs to
> > build longer on a stable platform.
> >
> > There will always be the possibility of major issues going somehow
> > unnoticed especially with new API. For that we could be more alert during
> > (technical) design and patch review when the Python API is touched. Bumping
> > the Python version can be considered part of the API we provide, so it
> > indeed
> > makes sense to take care about the proper planning of that as part of
> > scheduled breakage.
> >
> > These are good poings to bring up also during the dev meeting this coming
> > Monday 2019.09.19 (starting at 16:00 UTC).
> >
> > Finally the version scheme, I personally think moving to a semver scheme
> > would be useful for a wide array of installing (on a number of OSes) and
> > the add-on ecosystem as you noted.
> >
> > I hadn't thought of that since the summer, but lets see what the consensus
> > is regarding the version scheme. Having the dot added on the technical/code
> > side, and keeping the one without the second dot in the common tongue
> > might be worth considering, if not even completely move to it - currently
> > no strong opinion on that.
> >
> > Thanks again,
> >
> > /Nathan
> >
> > On Thu, Aug 15, 2019, 16:27 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
> > >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers