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

[Anton Khirnov]

Quoting James Almer (2023-01-18 22:23:43)
> 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.

I agree that it's probably not a big practical problem, but it is ugly
and goes against our claims of git master being stable.

> > I wonder if we couldn't come up with a better soltion. One thing that
> > comes to mind is setting the major version to 0 until the instability
> > period ends.
> 
> This could have several undesired effects, mainly for users looking at 
> that define and not really expecting such value (There are several 
> projects supporting more than one ffmpeg release and "MAJOR <= xx" 
> checks are commonplace).

IMO users who don't expect such a value shouldn't be linking against
unstable API/ABI anyway. We could also set the major version to
something really big, like 999. We'll have to change deprecation macros,
but that should be straightforward.

> Also, if we are going to code the instability period in some form into 
> the codebase, might as well make it so it starts with the first removal 
> commit, or immediately before it, so what you described above is no 
> longer a concern.

I'd rather say the two concerns merge into one, but it's not going away.
There's currently very little user indication that API/ABI are unstable
for several months.

-- 
Anton Khirnov