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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3575 bytes --]

On Wed, Jan 18, 2023 at 06:23:43PM -0300, James Almer wrote:
> 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).

API/ABI is defined by major minor patchlevel
these do have reasonable agreed upon meaning i think.

I dont think code pushed to master should break the promise the verions make.
If it breaks it, it should not be pushed. Not with VERY good reason, anything
could have some rare exception if theres a very good reason for the expcetion ...

A user or a script should always be able to checkout a version from master
and its major:minor:patchlevel versions should work as one would expect

I dont see why any exception is needed
A new major API will start with a new major version and 0 in minor obviously
now nothing at that time will depend on that major API version.
And once some other libs or apps depend on the new major API they at the
same time will require a minimum minor version and that minir version obviously
will be after the instability period because you cant really depend on unstable
API/ABI. So nothing would break from anything in that 0..X minor version range
because nothing should depend on that and after X things are after the instability
period. 
But we can still even in the instability period use the minor version for our
own inter lib dependancies and handle that in a somewhat clean way by bumping
minor when it is appropriate

PS: iam not sure i fully understood the reason behind why versions should be
set to "wrong" values during some period, so as always i might be missing
something

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".