[FFmpeg-devel] [PATCH 00/26] Major library version bump

[Anton Khirnov]

Quoting Leo Izen (2023-01-20 22:23:23)
> On 1/18/23 14:28, Anton Khirnov wrote:
> > Quoting James Almer (2023-01-16 14:38:14)
> >> It's been a while since the last bump, so it's time to do some cleaning and
> >> remove deprecated APIs. This will also give us an "Open ABI season" in which we
> >> can do breaking changes (like changing public struct offsets, public enum
> >> values, adding fields to structs that have their size tied to the ABI, etc) for
> >> a few weeks.
> > 
> > Last time this open season lasted something like half a year and only
> > ended when I arbitrarily said it did.
> > 
> > So I'd suggest to decide right now how long will the instability period
> > last (6 weeks should be enough for everybody) and write the end date at
> > the top of doc/APIchanges.
> > 
> > Another thing I'm not entirely happy about is versioning during the bump
> > and instability. While the remove-then-bump approach does make bisection
> > easier, it also creates commits that lie about their ABI version.
> > 
> 
> If the bump comes before the resulting removals, then wouldn't the 
> removals strictly speaking exist inside the instability period as they 
> immediately follow a version bump? This sounds like it keeps our promise.

With the way deprecation guards are typically structured, the bump
itself disables all deprecated code atomically. The removals then just
drop dead code. So even without an instability period this would work
"correctly" and that's how I used to do it.

However some people dislike so much code being disabled in a single
commit, since that is harder to bisect if the bump introduces any
issues..

-- 
Anton Khirnov