Re: Request for feedback: OpenEXR v2.2.1 .so version changes
Wayne Wooten <[email protected]> Thu, 21 Dec 2017 11:56:20 -0500
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <CAD49JLHX61QbKsfzutYonUVFxyN4Snpw=UwkJAE-G-CRHPXXGA@mail.gmail.com> |
--===============0515795130565340165== Content-Type: multipart/alternative; boundary="001a11401b1e5290190560dc9455" --001a11401b1e5290190560dc9455 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The Pixar team would prefer option A as well. =E2=80=94Wayne On December 21, 2017 at 8:48:15 AM, Larry Gritz ([email protected]) wrote: 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 <[email protected]> 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 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 aro= und "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 tha= n option a). Does the community have any strong positions on this either way? Francois. -- Larry Gritz [email protected] _______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel --001a11401b1e5290190560dc9455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style>= </head><body style=3D"word-wrap:break-word"><div id=3D"bloop_customfont" st= yle=3D"font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);mar= gin:0px;line-height:auto"><br></div> =C2=A0<div>=C2=A0The Pixar team would = prefer option A as well.</div><div>=C2=A0</div><div>=C2=A0 =E2=80=94Wayne<b= r> <div id=3D"bloop_sign_1513875332709693952" class=3D"bloop_sign"></div> <= br><p class=3D"airmail_on">On December 21, 2017 at 8:48:15 AM, Larry Gritz = (<a href=3D"mailto:[email protected]">[email protected]</a>) wrote:</p> <bl= ockquote type=3D"cite" class=3D"clean_bq"><span><div style=3D"word-wrap:bre= ak-word" class=3D""><div></div><div> <title></title> 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. <div class=3D""><br class=3D""> <div class=3D""><br class=3D""> <div> <blockquote type=3D"cite" class=3D""> <div class=3D"">On Dec 20, 2017, at 11:31 PM, Francois Chardavoine <<a href=3D"mailto:[email protected]" class=3D"">francois@lucasfilm= .com</a>> wrote:</div> <br class=3D"Apple-interchange-newline"> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"">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:</div> <div class=3D""><a href=3D"https://github.com/openexr/openexr/issues/250" c= lass=3D"">https://github.com/openexr/openexr/issues/250</a><br class=3D""><= /div> <div class=3D""><br class=3D""></div> 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. <div class=3D""><br class=3D""></div> <div class=3D"">Two options we can take are:</div> <div class=3D""> <ul class=3D""> <li class=3D"">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?")<br class=3D""></li> <li class=3D"">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 class=3D""></li> </ul> </div> <div class=3D""><br class=3D""></div> <div class=3D"">Does the community have any strong positions on this either way?</div> <div class=3D"">Francois.</div> </div> </div> </blockquote> </div> <br class=3D""> <div class=3D""> <div style=3D"word-wrap:break-word" class=3D""> <div style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-st= yle:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:norma= l;text-align:start;text-indent:0px;text-transform:none;white-space:normal;w= ord-spacing:0px"> --</div> <div style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-st= yle:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:norma= l;text-align:start;text-indent:0px;text-transform:none;white-space:normal;w= ord-spacing:0px"> Larry Gritz</div> <div style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-st= yle:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:norma= l;text-align:start;text-indent:0px;text-transform:none;white-space:normal;w= ord-spacing:0px"> <a href=3D"mailto:[email protected]" class=3D"">[email protected]</a></div> <div style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-st= yle:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:norma= l;text-align:start;text-indent:0px;text-transform:none;white-space:normal;w= ord-spacing:0px" class=3D""><br class=3D""></div> <br class=3D"Apple-interchange-newline"></div> <br class=3D"Apple-interchange-newline"></div> <br class=3D""></div> </div> _______________________________________________ <br>Openexr-devel mailing list <br><a href=3D"mailto:[email protected]">[email protected]</a= > <br><a href=3D"https://lists.nongnu.org/mailman/listinfo/openexr-devel">htt= ps://lists.nongnu.org/mailman/listinfo/openexr-devel</a> <br></div></div></span></blockquote></div></body></html> --001a11401b1e5290190560dc9455-- --===============0515795130565340165== 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 --===============0515795130565340165==--