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 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).
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'm also taking this opportunity to suggest a change in our deprecation period
policy. Until now it's been a generic two years period, with no concrete reason
for it other than giving library users "time" to migrate. What we have seen
however is that users migrate in two cases: As soon as things are deprecated
when they use git head to get rid of deprecation warnings, or when they have no
choice (aka, when they want to move their project to a new ffmpeg version that
no longer has the symbols they depended on).
In the latter case, any arbitrary amount of time will make no difference
whatsoever. Projects could right now still be using ffmpeg 4.3 (since that's
what Debian stable ships) and would not consider moving to 5.1 or any future
version for the foreseeable future. So the suggestion is to change to a release
based scheme, which will in some form be time based anyway. Namely, every three
releases we do a major bump, which will be a good year or so in real world
terms, in which all API deprecated during that period, as long as it's present
in a release, is removed. This would also go with the idea of a recurrent LTS
release, so if we do three releases per major version, it could be x.0 (initial
release) x.1 (LTS), and x.2 (last release made pre bump).
Sounds good to me.
If we go the above route, we could also remove API like the old lavu FIFO stuff,
a deprecation that's slightly less than a year old but effectively present in
v5.1.
We'd also need to add all this in writing, because this kind of policy can't
just be "oh yeah, we do it that way" in random emails.
But folklore is the most time-tested method of transmitting information.
_______________________________________________
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".
