On 9/8/2021 11:24 PM, Soft Works wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
James Almer
Sent: Thursday, 9 September 2021 03:57
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] Why does this break FATE?
[..]
Based on the fact that requirements are strict about MINOR bumps
and
mandating them to be included in the very commit that is requiring
the bump, I didn't expect that there's a different strategy for
MAJOR bumps.
A major bump is done once every few years to remove deprecated APIs
and
open the ABI for changes. After a major bump takes place, there's an
"Unstable ABI" period where one can make such breaking changes
(Altering
field offsets in public structs, adding new fields or changing their
types on structs that have their size tied to the ABI, changing
public
enum and #define values, etc).
A single major bump should encompass every breaking change during
this
short "unstable" period.
Why does there have to be an "unstable" period instead of making the
MAJOR bumps directly in those commits that are breaking ABI compatibility,
Is it about "saving" numbers?
To keep the bumping of major revision to a single number every few
years, yes. We decided to go the opposite way of x264.
Also, the FF_API defines would need to be updated way too often otherwise.
softworkz
_______________________________________________
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".
_______________________________________________
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".
