Request for feedback: OpenEXR v2.2.1 .so version changes

--===============9079758662913803275==
Content-Type: multipart/alternative; boundary="94eb2c04941cc5e4d40560d4afa6"

--94eb2c04941cc5e4d40560d4afa6
Content-Type: text/plain; charset="UTF-8"

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

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.

--94eb2c04941cc5e4d40560d4afa6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>It has been brought to our attention that the decisio=
n to increment the so version as part of the 2.2.1 release may be problemat=
ic:</div><div><a href=3D"https://github.com/openexr/openexr/issues/250">htt=
ps://github.com/openexr/openexr/issues/250</a><br></div><div><br></div>It w=
ould be great to get any additional community commentary on this. The .so v=
ersion was bumped up mainly as an (admittedly conservative) precautionary m=
easure, since it had been a long time since the previous release. Given tha=
t these are security vulnerability fixes, it&#39;s understandable that ther=
e might be in some cases a desire to be able to drop in replacement builds =
of OpenEXR without recompiling the host application.<div><br></div><div>Two=
 options we can take are:</div><div><ul><li>a)- patch the currently tagged =
2.2.1 to no longer include an .so version change. This could be controversi=
al unless we get feedback that no one has adopted 2.2.1 in any significant =
way yet (to avoid confusion around &quot;what version of 2.2.1 did you use?=
&quot;)<br></li><li>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).<br></li></ul></div><div><br></div><div>Does the com=
munity have any strong positions on this either way?</div><div>Francois.</d=
iv><div><br></div></div>

--94eb2c04941cc5e4d40560d4afa6--


--===============9079758662913803275==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel

--===============9079758662913803275==--