2024 Dependency Raise Plan - seeking feedback

[lgritz]

This discussion is for planning which dependency minimums we want to raise for the fall 2024 release. That is, in today's master branch that will be released in the second half of the year. None of this will affect the 2.5 release family.

Core compiler/language compatibility

I would like to propose that this be the year that we make the following major dependency changes as a baseline:

• C++: 14 -> 17
• gcc: 6.3 -> 9.3
• Other compilers: bump to whatever is the minimum needed to fully support C++17
• Python: 2.7 -> 3.7

So, first, if any of those are going to seriously be a problem for people (beyond needing to stay on OIIO 2.5 if you require those compatibility levels), please speak up ASAP.

Here are our compiler/language requirements (to the best of our knowledge), and for each one: the OIIO 2.5 minimum version supported, the current (mid-2024) version of that package, the mid-2021 version for reference (i.e., 3 years ago), and a proposal for a reasonable minimum for us to use for the last-2024 OIIO release.

Dependency	OIIO Min (year)	Current/ mid-2024	2021 version	Proposed Min (year) - reason	Done
C++	14 (2014)	23	20 (VP2021: 17)	17 (2017)	✅ #4199
gcc	6 (2016)	13	9.4	9.3 (2020) -- for C++17	✅ #4199
clang	3.4 (2014)	17/18?	11	5.0 (2017) -- C++17, maybe 8.0 (2019)?
MSVS	2017/19.10	2022	2019	19.14/MSVS2017 for full C++17 compat
icc classic	17 (2016)	2021/EOL	2021	19.0 (2020) -- needed for full C++17
icx	2022	16.0/2023.1	N/A	no change
Python	2.7 (2010, EOL 2020)	3.12	3.10	3.7 (2018) - finally drop 2.x	✅ #4200

(Note: "VP" means "VFX Platform Year".)

Other dependencies

Since we're presumably bumping these core dependency requirements anyway, we should think about what other dependencies to bump, since we're obviously willing to accept some significant dependency disruption.

The following chart of our other direct dependencies gives (to the best of our knowledge), and for each one: the OIIO 2.5 minimum version supported, the current (mid-2024) version of that package, the mid-2021 version for reference (i.e., 3 years ago), and a proposal for a reasonable minimum for us to use for the last-2024 OIIO release.

Please note that none of the proposed new minimums are less than 3 years old.

Dependency	OIIO Min (year)	Current/ mid-2024	2021 version	Proposed Min (year) - reason	Done
Boost	1.53 (2013)	1.84	1.77	REMOVE	✅ #4233
CMake	3.15 (2019)	3.28	3.20	?? 3.18 (2020) - Cuda and other helpful things 3.19 (2020)? = presets, more Cuda, Apple ARM 3.20 (2021)? = icx support, C++23 support
DCMTK (opt)	3.6.1 (2011?)	3.6.8	3.6.6	? 3.6.5 (2019)
FFmpeg (opt)	3.0 (2016)	6.1	4.3	? 4.0 (2018)
fmt	7.0 (2020)	10.2	8.0	8.0 (many improvements)
Freetype (opt)	unknown? test 2.8 (2017)	2.13	2.10.4	? 2.10.0 (2019) - to simplify testing
GIFlib	4.0 (1998)	5.2	5.2	5.0 (2012) - thread safety
libheif (opt)	1.3 (2018)	1.17	1.11	1.7 (2020) - color profiles, > 8 bit, generic metadata, avif support
libjpeg	6b? (2002?)	9f	9d	no change?
libjpeg-turbo (opt)	2.1 (2019)	3.0	2.1	no change?
libRaw (opt)	0.18 (2016)	0.21.2	0.20	0.20 (2020) - necessary for C++17	✅ #4217
libtiff	3.9 (2010)	4.6	4.3	At least 4.0 (2011) investigate advantages of newer
OpenColorIO (opt)	1.1 (2018)	2.3	2.0/2.1	2.0 - major new functionality
OpenCV (opt)	3.0 (2015)	4.9	4.5	4.0 (2018) - support for 'half', and allows other cleanup
OpenEXR/Imath	2.4 (2020)	3.2	3.1	3.1 (2021) - big compatibility jump, allows major cleanup	✅ #4223
OpenJPEG (opt)	2.0 (2015)	2.5	2.4	2.2 (multithread)
OpenVDB (opt)	5.0 (2017)	11.0	8.1	9.0 (2022) - required for OpenEXR 3.x compat	✅ #4218
PNG	1.5.13? (2012)	1.6.42		? 1.6.0 (2013) - allow some cleanup
Ptex (opt)	2.3.1 (2018) maybe older?	2.4.2	2.4.0	ok as is? Or bump to 2.3.2 per VP 2021?
pugixml	1.8	1.14	1.11.4	? 1.10 (2019)
pybind11	2.4.2 (2020)	2.11	2.7	? 2.7 (2021) or 2.6 (2020)
Qt (opt)	5.6 or 6.x	6.6?		no change?
Robin-map	0.6.2	1.2.2	0.6.3	1.2.2 (use latest since it's header only and used only internally)
TBB (opt)	2017	2021	2021	no pressing need?
WebP (opt)	0.6.1 (2017)	1.3.2	1.2	1.1 (2020) - exported configs

Discussion / The Ask

Please look over this list carefully

Here is what we would like to hear from stakeholders if you have strong opinions/needs:

• Do any of these proposed upgrades concern you? ("Hold on, don't upgrade that this year!")
  • Please pay particular attention to the jumps to OpenEXR/Imath, OpenColorIO, and CMake.
• Are we not being aggressive enough somewhere? ("If you're going to bump package XYZ, move all the way to version 8.0 for the following reason...")
• Should any of the optional dependencies be made required?
  • Should OpenColorIO be a required dependency to give a more reasonable baseline functionality of color management?

[scott-wilson]

I think that making OCIO a requirement is a good idea. It has been annoying in the past to debug a build of OIIO to find that it is not built with OCIO support. Also, I'm tempted to say that you probably want to make Python 3.9 the minimum, otherwise you're exchanging one unsupported Python version for another.

[lgritz]

The difference between Python 3.7 and 3.9 is not really discernible on the OIIO side. I'm not sure there is any complexity that can be saved by dropping 3.7 (in marked contrast to the huge amount of clutter we can discard once we get rid of 2.7!).

[hobbes1069]

One thing to keep in mind when making OCIO a hard dependency, when there's a soname bump in OIIO I have to do a bootstrap build first, because the version of OCIO will try to pull in the previous version of OIIO creating a conflict.

I would recommend working with OCIO and figuring out a way to remove the circular dependency first.

[lgritz]

@hobbes1069 The circular dependency has been gone for a long time now. OCIO can easily build using OpenEXR to read and write images and not need OpenImageIO at all.

[hobbes1069]

Whoops, obviously I missed that at some point :)

[lgritz]

Let me just explain how I'm looking at this philosophically. The decision to raise a dependency is generally hoping for at least one of these benefits:

• Unlocking OIIO functionality or reducing OIIO development work by being able to rely on the new features of a dependency. (Example, which is unfortunately not achievable this time around: I can't wait until our minimum OCIO is 2.2 and we can always rely on the built-in configs.)
• Reducing the burden of maintaining OIIO code for too many versions of a dependency. (Example: it's a huge clutter of #if in the code and a big mess for our build system to have to allow for both OpenEXR 2.x and 3.x. to be used.)
• Reduce the burden of testing against old versions that are increasingly difficult to keep working in our CI. At some point it's a tradeoff between having too many CI jobs to finish on time, or sampling too "sparsely" and failing to test important combinations, or dropping combinations from support.

And we are balancing those benefits against the inconvenience to users if we drop support for a dependency version that for other reasons they are stuck with.

[jessey-git]

Generally the compiler/language proposed minimums look fine. However, for the 19.14/MSVS 2019 line, which do you really mean? 19.14 is part of the VS 2017 series of releases, not 2019.

The dependency minimums seem fine as well. I don't have access to an environment but is that version of cmake available on rocky8 and friends?

[lgritz]

You're right, Jessey. That's just a typo / my frequently misremembering the confusing dual version designations of MSVS. I have fixed it above.

I think rocky8 may be an even more recent cmake than that. But in any case, many of the other open source projects in our ecosystem already require even more recent versions (see here) so I don't think that in any of these cases it's going to be us as the sole push for people to upgrade anything.

[JGoldstone]

At least 3.19 for ARM support, please.

I get that the time for it is not now, but here's a nice summary of CMake releases, with 3.24 having some (to me) quite appealing features regarding missing dependency resolution. Pull quote:

Package writers are getting integration between find_package and FetchContent that will allow "download if missing" workflows, and is configurable by packagers.

http://cliutils.gitlab.io/modern-cmake/chapters/intro/newcmake.html

Someday. But probably not our 3.0 release, as initial release was of that version (3.24) of CMake was only a year and a half ago. (And perhaps, having never had to write the relevant CMake from scratch myself, "download if missing" workflows aren't all that hard to provide; I really don't know.)

But at least 3.19, please.

[lgritz]

Thanks, Joseph, that's a really handy page of top changes per cmake version!

What is the 3.19 feature that makes things better for ARM?

Even if we don't bump the minimum across the board, we can definitely modify the docs to suggest people use 3.19 or newer if they are building on Mac ARM and probably have the build warn if that is occurring.

[JGoldstone]

See here, a ways down:

http://cliutils.gitlab.io/modern-cmake/chapters/intro/dodonot.html

under 'What minimum to choose - OS support'

[lgritz]

In the OIIO TSC meeting of Feb 26, Thiago suggested moving the clang minimum version up more aggressively, to the older of: (a) whatever LLVM version OSL needs, or (b) whatever the clang version is in the rpm package for rhel7/CentOS-7, since that's easy for studio users who will be lagging behind the farthest. Anything older is probably not needed by anybody, and just makes it more difficult for us to test and ensure that we really do work with the very ancient versions.

LG suggests that we can do a "soft" minimum where we advertise/document 9.0 (say) as the minimum, and warn in the build for older compilers, but don't purposely cause it to fail. Because it probably still works with older versions, so if we have nothing specific to gain with an enforced hard minimum, why make life hard for user who is stuck with an old version? (This is predicated on the claim that there are few, if any, #if clauses or other complexities where we maintain extra code to accommodate older clang versions.)

Action item: LG will check on the CentOS and OSL versions and adjust the table.

[ThiagoIze]

Do we want to add robin-map to the list of dependencies?

[lgritz]

yeah, will do

[lgritz]

I think the reason I omitted it is since we auto-download it, and it's used only internally and not in any of our public APIs), I believe we can upgrade at any time and/or always stay on the latest, without any compatibility breaks for users/builders of OIIO.

[ThiagoIze]

I thought it's still optional using BUILD_MISSING_ROBINMAP? Users could use their own copy, which they might want to if for instance they are stuck on an older version of OIIO, which in turn is using an old robin-map, but want to update robin-map because it fixes a bug or has a patched security vulnerability.

[lgritz]

Yes, if it's found locally, it won't download a new one.

But there's no new "feature" of robin-map we need. So we don't enforce a minimum. That's why it wasn't on the list, I see now. We might bump up the recommended version, or the version we get ourselves if it's not found, but at the moment we don't a reason to force a different minimum.