[PATCH libICE 1/7] Added visibility annotations.

Emil Velikov emil.l.velikov at gmail.com
Mon Sep 4 15:10:00 UTC 2017


[Adding Julien]

Hi all,

On 12 May 2016 at 14:18, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 9 May 2016 at 17:52, Adam Jackson <ajax at nwnk.net> wrote:
>> On Sun, 2016-05-08 at 09:19 +0100, Emil Velikov wrote:
>>> From: Yury Gribov <y.gribov at samsung.com>
>>>
>>> This allow us to be good citizen by hiding the private symbols and
>>> reducing the overall size of the binary.
>>>
>>> Note: _IceTransNoListen must be exported (albeit being a non-public
>>> symbol) as explained in the comment just above it.
>>>
>>> Signed-off-by: Yury Gribov <y.gribov at samsung.com>
>>>
>>> v2:
>>>  - Add commit message.
>>>  - Reuse existing CFLAGS
>>>  - Add a beefy comment about the _IceTransNoListen export.
>>>
>>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>>
>> The only question I have remaining here is how many version numbers we
>> should bump to reflect this change. I think I can be convinced that
>> bumping the soname isn't wholly necessary since clients were already
>> going off-label to get at this API in the first place, but it'd be nice
>> to see at least the package major number bumped so it's extremely
>> obvious where the break happened.
>>
> I'm leaning towards "bump the major" as we could have unintentionally
> broken things. If we have we can add the symbols back and release a
> minor that brings them back. I'll send a patch in a second.
>
>> Assuming we do that, series is:
>>
>> Reviewed-by: Adam Jackson <ajax at redhat.com>
>>
In hindsight my earlier suggestion [bump the major] was extremely pedantic.

At the same time, I just did another local search for potential users
an this patch seems to handle them all.
Aka no users should be broken this patch. That combined with the brief
reply by Julien [1] let's go for a minor bump.

Does that sound reasonable? If so I can follow-up with a patch.

Thanks
Emil

[1] https://patchwork.freedesktop.org/patch/86676/


More information about the xorg-devel mailing list