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

[Tomas Härdin]

ons 2023-01-18 klockan 18:23 -0300 skrev James Almer:
> On 1/18/2023 4:28 PM, 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.
> 
> Does it really matter? All the patches will be pushed at the same
> time, 
> meaning one git fetch will give you a stable state pre bump and the
> next 
> will be right after it.
> I think it's a bit farfetched to expect someone to pick a random
> commit 
> in the middle of the bump and try to use the resulting compiled 
> libraries with some program that was linked to some earlier version 
> libraries.

This is easily fixed by having a feature branch for the bumps and
merging it with --no-ff. git bisect is clever enough to skip past such
things

/Tomas