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@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@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@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers