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 the 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
<rich...@wetafx.co.nz <mailto:rich...@wetafx.co.nz>> 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.
—Wayne
On December 21, 2017 at 8:48:15 AM, Larry Gritz
(l...@larrygritz.com <mailto:l...@larrygritz.com>) 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
<franc...@lucasfilm.com <mailto: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 <mailto:l...@larrygritz.com>
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org <mailto:Openexr-devel@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/openexr-devel
<https://lists.nongnu.org/mailman/listinfo/openexr-devel>
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org <mailto:Openexr-devel@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/openexr-devel
<https://lists.nongnu.org/mailman/listinfo/openexr-devel>
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org <mailto:Openexr-devel@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/openexr-devel
<https://lists.nongnu.org/mailman/listinfo/openexr-devel>
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
