Re: Request for feedback: OpenEXR v2.2.1 .so version changes
Francois Chardavoine <[email protected]> Thu, 21 Dec 2017 22:03:02 -0800
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <CADBZUEj7upsLtjaa1nNZcAhYy0Gu03ZDiG39XB-ebZ=qFx=bhw@mail.gmail.com> |
--===============4710295979412739641== Content-Type: multipart/alternative; boundary="001a113dc680f9af490560e792bb" --001a113dc680f9af490560e792bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Only doing option a) avoids the confusion about "what's different between the two versions?" down the road, but your points are valid and doing both, while feeling like overkill, certainly covers all the bases. On Thu, Dec 21, 2017 at 5:30 PM, Richard Addison-Wood <[email protected]= > wrote: > Basically, a 2.2.2 release would be in the correct form without the the > questions about whether it is the correct variation. Anyone looking to > grab the latest 2.2.* would get the security fix as a drop-in replacement > for 2.2.0. > > A new 2.2.1 release would be in the correct form, but there is the > possibility that the wrong variation as escaped during the window between > the first release and the correction. Issue #250 certainly shows that th= e > original 2.2.1 has been picked up. > > We would want to deprecate the 2.2.1 releases because of the ambiguity. > But, the new official corrected 2.2.1 would still be valid. > > I am curious about the reasons why it might be preferable to only doing > option a. > > As a reminder, we really do want to keep the bumps in version info in the > namespace and the SONAME synchronized. > > > On 12/22/17 12:29, Francois Chardavoine wrote: > > Why do b) as well if we go with a) ? > > > On Thu, Dec 21, 2017 at 1:52 PM, Richard Addison-Wood < > [email protected]> wrote: > >> How about both options a and b? >> >> >> On 12/22/17 05:56, Wayne Wooten wrote: >> >> >> >> 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 yo= u >> 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. Th= e >> .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 th= at 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 cle= aner >> than 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 >> >> >> >> _______________________________________________ >> Openexr-devel mailing [email protected]://lists.nongnu.o= rg/mailman/listinfo/openexr-devel >> >> >> >> _______________________________________________ >> Openexr-devel mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/openexr-devel >> >> > > --001a113dc680f9af490560e792bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Only doing option a) avoids the confusion about "what= 's different between the two versions?" down the road, but your po= ints are valid and doing both, while feeling like overkill, certainly cover= s all the bases.<div><br></div><div><br></div></div><div class=3D"gmail_ext= ra"><br><div class=3D"gmail_quote">On Thu, Dec 21, 2017 at 5:30 PM, Richard= Addison-Wood <span dir=3D"ltr"><<a href=3D"mailto:[email protected]"= target=3D"_blank">[email protected]</a>></span> wrote:<br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> =20 =20 =20 <div text=3D"#000000" bgcolor=3D"#FFFFFF"> Basically, a 2.2.2 release would be in the correct form without the the questions about whether it is the correct variation.=C2=A0 Anyone looking to grab the latest 2.2.* would get the security fix as a drop-in replacement for 2.2.0.<br> <br> A new 2.2.1 release would be in the correct form, but there is the possibility that the wrong variation as escaped during the window between the first release and the correction.=C2=A0 Issue #250 certainl= y shows that the original 2.2.1 has been picked up.<br> <br> We would want to deprecate the 2.2.1 releases because of the ambiguity.=C2=A0 But, the new official corrected 2.2.1 would still be valid.<br> <br> I am curious about the reasons why it might be preferable to only doing option a.<br> <br> As a reminder, we really do want to keep the bumps in version info in the namespace and the SONAME synchronized.<div><div class=3D"h5"><br= > <br> <div class=3D"m_-846089722320215962moz-cite-prefix">On 12/22/17 12:29, = Francois Chardavoine wrote:<br> </div> <blockquote type=3D"cite"> =20 <div dir=3D"ltr">Why do b) as well if we go with a) ? <div><br> <div class=3D"gmail_extra"><br> <div class=3D"gmail_quote">On Thu, Dec 21, 2017 at 1:52 PM, Richard Addison-Wood <span dir=3D"ltr"><<a href=3D"mailto:= [email protected]" target=3D"_blank">[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"> <div text=3D"#000000" bgcolor=3D"#FFFFFF"> How about both options a and b? <div> <div class=3D"m_-846089722320215962h5"><br> <br> <div class=3D"m_-846089722320215962m_-372715523871274= 3362moz-cite-prefix">On 12/22/17 05:56, Wayne Wooten wrote:<br> </div> <blockquote type=3D"cite"> <div id=3D"m_-846089722320215962m_-3727155238712743= 362bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:13px;co= lor:rgba(0,0,0,1.0);margin: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<br> <br> <p class=3D"m_-846089722320215962m_-3727155238712= 743362airmail_on">On December 21, 2017 at 8:48:15 AM, Larry Gritz (<a href=3D"mailto:[email protected]" target=3D= "_blank">[email protected]</a>) wrote:</p> <blockquote type=3D"cite" class=3D"m_-84608972232= 0215962m_-3727155238712743362clean_bq"><span> <div style=3D"word-wrap:break-word"> <div> I don't have a strong opinion, bu= t 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><br> <div><br> <div> <blockquote type=3D"cite"> <div>On Dec 20, 2017, at 11:31 PM, Francois Chardavoine <<a href=3D"mailto:francois@= lucasfilm.com" target=3D"_blank">[email protected]</a>> wrote:</div> <br class=3D"m_-84608972232021596= 2m_-3727155238712743362Apple-interchange-newline"> <div> <div dir=3D"ltr"> <div>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><a href=3D"https://githu= b.com/openexr/openexr/issues/250" target=3D"_blank">https://github.com/open= exr/ope<wbr>nexr/issues/250</a><br> </div> <div><br> </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 understandabl= e 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><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 controversial unless we get feedback that no one has adopted 2.2.1 in any significant way yet (to avoid confusion around "what versi= on of 2.2.1 did you use?")<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 community have any strong positions on this either way?</div> <div>Francois.</div> </div> </div> </blockquote> </div> <br> <div> <div style=3D"word-wrap:break-word"= > <div style=3D"color:rgb(0,0,0);fo= nt-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:norm= al;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0p= x;text-transform:none;white-space:normal;word-spacing:0px">--</div> <div style=3D"color:rgb(0,0,0);fo= nt-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:norm= al;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0p= x;text-transform:none;white-space:normal;word-spacing:0px">Larry Gritz</div> <div style=3D"color:rgb(0,0,0);fo= nt-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:norm= al;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0p= x;text-transform:none;white-space:normal;word-spacing:0px"><a href=3D"mailt= o:[email protected]" target=3D"_blank">[email protected]</a></div> <div style=3D"color:rgb(0,0,0);fo= nt-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:norm= al;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0p= x;text-transform:none;white-space:normal;word-spacing:0px"><br> </div> <br class=3D"m_-84608972232021596= 2m_-3727155238712743362Apple-interchange-newline"> </div> <br class=3D"m_-846089722320215962m= _-3727155238712743362Apple-interchange-newline"> </div> <br> </div> </div> ______________________________<wbr>______= ___________ <br> Openexr-devel mailing list <br> <a href=3D"mailto:[email protected]= g" target=3D"_blank">[email protected]</a> <br> <a href=3D"https://lists.nongnu.org/mailm= an/listinfo/openexr-devel" target=3D"_blank">https://lists.nongnu.org/mailm= <wbr>an/listinfo/openexr-devel</a> <br> </div> </div> </span></blockquote> </div> <br> <fieldset class=3D"m_-846089722320215962m_-37271552= 38712743362mimeAttachmentHeader"></fieldset> <br> <pre>______________________________<wbr>___________= ______ Openexr-devel mailing list <a class=3D"m_-846089722320215962m_-3727155238712743362moz-txt-link-abbrevi= ated" href=3D"mailto:[email protected]" target=3D"_blank">Openexr-de= [email protected]</a> <a class=3D"m_-846089722320215962m_-3727155238712743362moz-txt-link-freetex= t" href=3D"https://lists.nongnu.org/mailman/listinfo/openexr-devel" target= =3D"_blank">https://lists.nongnu.org/mailm<wbr>an/listinfo/openexr-devel</a= > </pre> </blockquote> <br> </div> </div> </div> <br> ______________________________<wbr>_________________<br> Openexr-devel mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a><br> <a href=3D"https://lists.nongnu.org/mailman/listinfo/openex= r-devel" rel=3D"noreferrer" target=3D"_blank">https://lists.nongnu.org/mail= m<wbr>an/listinfo/openexr-devel</a><br> <br> </blockquote> </div> <br> </div> </div> </div> </blockquote> <br> </div></div></div> </blockquote></div><br></div> --001a113dc680f9af490560e792bb-- --===============4710295979412739641== 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 --===============4710295979412739641==--