Re: Request for feedback: OpenEXR v2.2.1 .so version changes
Larry Gritz <[email protected]> Thu, 21 Dec 2017 08:47:29 -0800
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============2914127295129768730== Content-Type: multipart/alternative; boundary="Apple-Mail=_0D3A2DCC-336C-4E93-B6A5-226DC73AFEE8" --Apple-Mail=_0D3A2DCC-336C-4E93-B6A5-226DC73AFEE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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: >=20 > 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> >=20 > 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. >=20 > 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). >=20 > Does the community have any strong positions on this either way? > Francois. -- Larry Gritz [email protected] --Apple-Mail=_0D3A2DCC-336C-4E93-B6A5-226DC73AFEE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">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"">[email protected]</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" = class=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; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space;" class=3D""><div style=3D"color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: = normal; font-variant-caps: normal; font-weight: normal; letter-spacing: = normal; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px;">--</div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 14px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;">Larry = Gritz</div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 14px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 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-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 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></body></html>= --Apple-Mail=_0D3A2DCC-336C-4E93-B6A5-226DC73AFEE8-- --===============2914127295129768730== 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 --===============2914127295129768730==--