On Mon, Oct 3, 2022 at 10:45 PM David Yu <
davi...@gmail.com> wrote:
>
> Hi Neal,
>
> Thank you for your reply!
>
> We do regret not engaging earlier with the CY2023 process, but we did want to use this window of opportunity to help with the successful adoption of CY2023 (more below).
>
> I agree with your good points about ABI compatibility. Moving to 3.5.x leaves this behavior unchanged, though we do look forward to improving this in the future.
>
> As for other benefits of moving to 3.5.x:
> - We've done additional work to address compiler warnings and errors with GCC 11 and VS2022 and recent Apple platforms.
> - We've addressed build compatibility issues with CMake 3.x and Python 3.
> - Last but not least, we think the additional subdivision surface evaluation methods in this release will be important and helpful to studios and VFX application developers going forward.
>
> Happy to answer any questions!
>
That sounds great! Would it be possible to fix the soname for
OpenSubdiv so that newer 3.5.x releases don't require rebuilding
everything to use it? Right now, we ship OpenSubdiv in Fedora, and
every library upgrade requires rebuilding its reverse dependencies
because the user-facing version is encoded as the shared object
version too. That is. OpenSubdiv 3.5.0 produces libosdCPU.so.3.5.0 and
libosdGPU.so.3.5.0, and 3.5.1 bumps the soversion to 3.5.1, and so on.
This is unnecessarily punishing for consumers of the library.
If OpenSubdiv is major version compatible, then the soversion should
just be 3, if it's major+minor compatible, then it should be 3.5, and
this should not change as new versions that don't break API+ABI are
made. Once an API and/or ABI break occurs, then the library version
should bump.