Branching this weekend

[Nick Alcock]

On 30 Jul 2024, Nick Clifton outgrape:

> Hi Nick,
>
>>> Correct - I will be evaluating the branch for at least 2 weeks.
>> Presumably there's no objection to bugfixes and reversals of
>> in-hindsight-ill-advised changes made in trunk between the branch and
>> release? I have some libctf stuff coming up in the next day or so...
>
> Bug fixes - please go ahead.
>
> API reversals are ... more of a grey area.  If the bit of the API
> that you are changing is new - ie not yet in any binutils release -
> then changing it is OK.

It is. And the API thing was more of a "this is a new restriction too
far -- lift it by default", so it acts like it used to in earlier
releases.

>                          (As long as you are sure that the change
> is correct).  If the part that you want to change is an established
> component of the API then I would be against the change.

It's a new API function which can be used to set a flag which changes
the ctf_add_enumerator() API so it works differently from how it does in
trunk (but like it did in previous releases, since that change broke
real users).

>                                                           Last minute
> changes often have repercussions that are not apparent at the time
> that they are made.  So giving a change time to percolate in the
> development sources is usually a good idea.

Absolutely! If you'd rather I hold off with the API part of things, I
can do that. (At least one of the bugfixes is... more urgent, since it
can be used to cause writing into freed memory, ugh. That one I'm
backporting all the way to its introduction.)

-- 
NULL && (void)