[Bf-committers] Proposal for clarified VFX Reference Platform Support

Brecht Van Lommel brechtvanlommel at gmail.com
Mon Jan 24 13:08:40 CET 2022


There are definite trade-offs, but a few things:
* Linux distribution packages are not expected to follow the VFX platform.
They have always deviated in the library versions compared to our own
builds, including the Python version.
* Upgrading to the latest Python version is not the only way to fix bugs,
we can also patch our Python build with a fix for the rare case that
happens and is important.
* The platform library versions are not that old, and in some cases it has
made us upgrade quicker. We've never tracked the latest libraries closely
for every Blender release.
* At least for me, tracking to the VFX platform did not stop me making
upstream contributions or fixing build issues with latest versions of
libraries.
* It's not clear to me how the VFX platform could negatively affect studios
making contributions to Blender, that would be an argument against LTS
releases if anything.
* Studios will stick to a particular platform for the duration of a
project, and in parallel use newer platforms for new projects. That's the
sane option for them regardless if we like it.


On Mon, Jan 24, 2022 at 12:28 PM Sybren A. Stüvel via Bf-committers <
bf-committers at blender.org> wrote:

>  On Fri, Jan 21, 2022 at 02:27:19PM +0100, Dalai Felinto via Bf-committers
> wrote:
> > To have studios contributing to Blender is a two-way street. And Blender
> > sticking to the VFX is the least the Blender project can do on its end.
>
> This seems to ignore the fact that we've already broken with the VFX ref
> platform when it comes to the Python version. It was done simply because a
> Blender-crashing bug was fixed in Python, and the only way to get that fix
> was to get a newer version of Python.
>
> On Fri, 21 Jan 2022 at 16:31, Sebastian Parborg via Bf-committers <
> bf-committers at blender.org> wrote:
>
> > It will lead to very rigid and stale development environment which will
> > use obsolete library versions and APIs even before we do a new release.
> > Our developers will not be able to be agile when handling library
> > related issues or follow upstream development incrementally. This also
> > means that we can't collaborate with upstream that well either.
> >
>
> This is also what I suspect might happen when we take the stance to stick
> to the VFX platform.
>
>
> > To me the easiest solution would simply just to take the stance that if
> > someone wants to use a frozen and outdated target platform, then they
> > can simply just use an older version of Blender that uses the required
> > python version and libraries.
> >
>
> Part of the problem is that the VFX platform is all over the place when it
> comes to the age of the libraries. It's not just sticking to old versions,
> but also has suggested a version of OpenEXR that wouldn't even be released
> yet. It's the combination of unusably old and not-yet-usable new that
> boggles my mind. There is no old version of Blender that matches the old
> versions of the VFX ref platform, because there is no moment in time when
> all those versions were considered "current".
>
> Sybren
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list