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 _______________________________________________ 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".
