That's a good question!
There are two subtly different issues:
1. Which VFX Platform years should we be ensuring that the current OIIO dev and
release branches will build on?
2. Which older OIIO releases are we obligated to continue to support, both with
bug fixes as well as updates to keep compatibility with new versions of our
dependencies (e.g., when OpenEXR 3.0 is released, does OIIO 2.1 need to be
updated to be able to build against it?).
The second issue is easier. We do a major release yearly, and liberally
backport fixes and non-ABI-breaking enhancement to the current supported
release family (now 2.2.x, which gets a minor release like clockwork every
month). The prior release family (now 2.1.x) only is updated for very critical
bugs and only upon request. Nothing older is ever patched.
The combination of how quickly people upgrade their OIIO and how stable and
mature it is means that there is very little demand that I'm seeing for patches
to anything other than the current release family. I'm just following the
users' lead for the most part.
Now back to the harder question -- which set of compilers and other
dependencies do we need to support with the current and dev releases? There is
unfortunately no hard rule about this, just a bunch of heuristics and
surveillance of the major studios, such as: What's the oldest version of Maya
people are still using? What is the default compiler in the version of CentOS
that most of the studios are using? Users may freely update and rebuild OIIO,
but they can't easily change their studio's OS or which version of a DCC app
their in-progress show has locked onto.
At work, we're just now ending our internal requirements for gcc4.8/C++11
compatibility (which was driven by the toolchain we chose years ago for our
Maya 2019 plugin ecosystem). It's not really that we're only now starting
gcc6/C++14... we've been building that as well, multiple versions of everything
to serve the several DCC apps with different requirements. But it's only in the
last few weeks that a particular show is winding down that was the very last on
the old toolchain. We don't yet have a show *requiring* C++17, but we surely
will soon, since that's the CY 2021 requirement of the DCC apps.
So that means that just now, our need to support VFX Platform 2017 (the last to
use gcc4.8) can be retired. I guess that makes our effective minimum 2018? Or
maybe 2019? It's not 2020, because all the studios are still needing Python
2.7, and technically that is VFXP 2019.
Exactly when can we stop supporting CY2019 and drop Python 2.7 support? When
can we stop supporting CY2020 and move to C++17/gcc9? The answers to those are
currently unknown, but at my studio we're at least a year away for both of
those.
I am hoping to coax some combination of ASWF TAC and VFX Platform into
stipulating sunset dates for VFX Platform years, clear guidance where they say,
for example, "here are the compatibilities for CY2022, and also nobody should
count on continued support for <=2019 from this point onward, and software
projects need not support them." I think that we could all live closer to the
most recent releases if the whole ecosystem were agreed on when we retired the
old versions. But right now, all the projects are just guessing, and that leads
to being pretty conservative about what you support.
-- lg
> On Mar 27, 2021, at 5:29 PM, Solomon Boulos <bou...@cs.stanford.edu> wrote:
>
> That makes sense.
>
> Would you describe OIIO’s development branch as needing to be compatible with
> VFX’s Reference Platform CY of N-2 or N-1? (N-3?).
>
> How about the oldest release branch that will receive bug fixes and be
> ensured to pass CI? N-3 to do a full show? N-5 because you locked at the
> start of the show and were behind at the time? :).
>
> On Sat, Mar 27, 2021 at 14:32 Larry Gritz <l...@larrygritz.com
> <mailto:l...@larrygritz.com>> wrote:
> We're only just now wrapping the last show that uses a software stack based
> on gcc4.8/C++11. It will probably be a couple more years before we (and
> everybody else who uses OIIO) are totally free of the need to be compatible
> with prior years' DCC apps that are gcc6/C++14. As a core library used across
> many products and apps, we just can't require users to be closer to the
> bleeding edge than other apps they depend on and need to link against.
>
> I'm hopeful that the ASWF TAC and/or VFX Platform can be urged to give
> definitive guidance on how many prior years of VFX Platform should continue
> to be supported by the foundational open source libraries. VFX Platform CY
> 2021 was the first to be C++17, so if/when we can get a clear sunset date on
> compatibility with CY 2020, we'll know when we can drop 14.
>
>
>> On Mar 27, 2021, at 1:13 PM, Solomon Boulos <bou...@cs.stanford.edu
>> <mailto:bou...@cs.stanford.edu>> wrote:
>>
>> Why not make the jump to 17 now? There are a lot of nice bonuses in C++17 (
>> https://isocpp.org/files/papers/p0636r0.html
>> <https://isocpp.org/files/papers/p0636r0.html> is a reasonable summary) and
>> given how long you’ve been on C++11, it seems like it’d be a while before
>> upgrading again. Unless you figure you’d do the C++17 upgrade next year?
>>
>> On Sat, Mar 27, 2021 at 12:52 Larry Gritz <l...@larrygritz.com
>> <mailto:l...@larrygritz.com>> wrote:
>> https://github.com/OpenImageIO/oiio/pull/2918
>> <https://github.com/OpenImageIO/oiio/pull/2918>
>>
>> This is just testing the waters by changing the *default* compatibility mode
>> from C++11 to C++14, but not yet dropping support for C++11, to shake
>> anything loose that will be trouble for people. For now, you can keep
>> compiling master with C++11 by using -DCMAKE_CXX_STANDARD=11 on the cmake
>> configure step.
>>
>> But the bump of the true minimum to C++14 (and dropping of gcc 4.8 and MSVS
>> 2015) is IMMINENT.
>>
>> For perspective, VFX Platform has specified C++14 since 2018, and specifies
>> C++17 for 2021. So this is not exactly a bleeding edge move.
>>
>> Of course, I'm only talking about master (future OIIO >= 2.3). Compilers,
>> standards, and other dependencies will never be removed from supported
>> release branches (currently 2.2). Nothing stops people from using 2.2 if
>> they need compatibility with older dependencies or build tools.
>>
>> I'm also thinking that by the time we release OIIO 2.3, other dependencies
>> may also have their minimum versions raised. For example, we currently
>> support OpenEXR as far back as 2.0 (2012!).
>>
>> So let this be the final notice -- if you are expecting OIIO 2.3 (not
>> officially released/supported until the second half of 2021) to be
>> compatible with gcc 4.8, C++11, MSVS < 2017, or to build against any
>> versions of its dependencies that are older than 2016, please speak up now
>> and we can discuss these requirements.
>>
>>
>> --
>> Larry Gritz
>> l...@larrygritz.com <mailto:l...@larrygritz.com>
>>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>
> --
> Larry Gritz
> l...@larrygritz.com <mailto:l...@larrygritz.com>
>
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
l...@larrygritz.com
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
