Glibc stable release process (Glibc 2.26.1)
Carlos O'Donell
carlos@redhat.com
Wed Oct 4 14:06:00 GMT 2017
On 10/04/2017 06:32 AM, Florian Weimer wrote:
> On 10/04/2017 02:52 PM, Arjan van de Ven wrote:
>> On 10/4/2017 1:36 AM, Andreas Schwab wrote:
>>> On Okt 04 2017, Siddhesh Poyarekar <siddhesh@sourceware.org>
>>> wrote:
>>>
>>>> 0. Must not break ABI on that branch
>>>
>>> We must not break the ABI on any branch. What you probably mean
>>> is that we must not extend the ABI on the release branch.
>>
>> and no new symvers
>>
>> I'd expect this to be both backward (like usual) but also forward
>> compatible as a goal.
>>
>> now if a CVE requires a new symver, I'm sure that will trump that
>> rule
>
> No, if a new symbol version is required, we cannot backport the fix.
> We need to leave it unfixed or come up with a different fix.
Agreed. We should not be adding new symbol versions to stable branches.
Likewise as Joseph and Andreas mentioned, we should not be changing
the semantics of GLIBC_PRIVATE symbols, nor adding new ones, they can
and will crash processes as glibc is updated.
--
Cheers,
Carlos.
More information about the Libc-alpha
mailing list