I don't have a strong opinion, but the widely used convention is that you should bump the so version when link compatibility changes. I'm ok with (a), I don't think I've yet seen 2.2.1 in the wild.
> On Dec 20, 2017, at 11:31 PM, Francois Chardavoine <franc...@lucasfilm.com> > wrote: > > It has been brought to our attention that the decision to increment the so > version as part of the 2.2.1 release may be problematic: > https://github.com/openexr/openexr/issues/250 > <https://github.com/openexr/openexr/issues/250> > > It would be great to get any additional community commentary on this. The .so > version was bumped up mainly as an (admittedly conservative) precautionary > measure, since it had been a long time since the previous release. Given that > these are security vulnerability fixes, it's understandable that there might > be in some cases a desire to be able to drop in replacement builds of OpenEXR > without recompiling the host application. > > Two options we can take are: > a)- patch the currently tagged 2.2.1 to no longer include an .so version > change. This could be controversial unless we get feedback that no one has > adopted 2.2.1 in any significant way yet (to avoid confusion around "what > version of 2.2.1 did you use?") > b)- release a 2.2.2 version which is identical to 2.2.1, except with the > older so version. This is somewhat inelegant, but likely cleaner than option > a). > > Does the community have any strong positions on this either way? > Francois. -- Larry Gritz l...@larrygritz.com
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
