On 1/19/2023 4:26 AM, Anton Khirnov wrote:
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.
How about making minor == 0 mean unstable? Some projects like GCC do it
like this, for example. Said version would not guarantee anything at all
and should not be linked against. Then once the period ends after the
major bump, it's bumped to 1, and the usual "new API, minor bump" rule
kicks in.
This also means that any API addition that takes place during the
unstable period doesn't get it's own version, and they will all strictly
speaking be introduced by minor 1.
As for your concern about first removing then bumping meaning we're
lying about the ABI, the first commit in the set could maybe rollback
minor to 0, then apply the removals, and finally the major bump in the
last commit. It will that way be considered unstable for the whole thing.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
