On Sun, 29 Nov 2015 23:58:16 -0300
James Almer <jamr...@gmail.com> wrote:
> On 11/29/2015 11:45 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Nov 29, 2015 at 9:41 PM, Ganesh Ajjanagadde <gajjanaga...@gmail.com>
> > wrote:
> >
> >> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
> >> resulted in wasted space under --enable-hardcoded-tables:
> >> dynamic: 1318672 libavutil/libavutil.so.55
> >> old : 1330680 libavutil/libavutil.so.55
> >> new : 1326488 libavutil/libavutil.so.55
> >>
> >> Minor version number is bumped.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com>
> >> ---
> >> libavutil/crc.h | 2 +-
> >> libavutil/version.h | 2 +-
> >> 2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavutil/crc.h b/libavutil/crc.h
> >> index e86bf1d..61592df 100644
> >> --- a/libavutil/crc.h
> >> +++ b/libavutil/crc.h
> >> @@ -40,7 +40,7 @@ typedef enum {
> >> AV_CRC_32_IEEE,
> >> AV_CRC_32_IEEE_LE, /*< reversed bitorder version of AV_CRC_32_IEEE */
> >> AV_CRC_16_ANSI_LE, /*< reversed bitorder version of AV_CRC_16_ANSI */
> >> - AV_CRC_24_IEEE = 12,
> >> + AV_CRC_24_IEEE,
> >> AV_CRC_MAX, /*< Not part of public API! Do not use outside
> >> libavutil. */
> >> }AVCRCId;
> >
> >
> > I support the idea, but this breaks ABI. You need to do this under a
> > version bump, see libavutil/version.h for templates.
>
> One could argue no releases have been made since the last major bump, so
> breakages
> like this are unlikely to affect anyone. But then again, it's been months
> since said
> major bump.
> What's been chosen in previous bumps as the drawing line for ABI breakages?
> Some
> arbitrary amount of time after the last bump (like the month mentioned in
> APIChanges),
> or first release post bump?
Yes, I guess the phase for arbitrary ABI changes after a major bump
might be over.
There's apparently no reason to keep ABI compatibility within git. It's
the development tree after all, and for those who need ABI compat, we
have releases.
But it has been argued that keeping ABI compat makes ti easier to
cherry-pick patches into the release trees.
If we decide to allow breaking ABI in git is ok (maybe clearly
expressed in the commit message to avoid accidents), then I'd say the
major version numbers should be bumped after every major release.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
