[x265] Poor Development Practices

[Steve Borho]

On Tue, Feb 18, 2014 at 9:46 AM, Derek Buitenhuis <
derek.buitenhuis at gmail.com> wrote:

> So.
>
>
> https://bitbucket.org/multicoreware/x265/commits/b1f5fd61883a0f375bbb5012fc41a5661c0b9389
>
> This introduced an API change with NO version bump.
>

This was my fault; I was uncertain about the guarantees of the build
number. It mainly seems to function as a link guard to prevent linking to a
library with a different API.  But this particular change did not actually
change the API; that particular field had always been effectively the
internal bit depth for the shared library.  So ffmpeg would have been able
to link to and use libraries built after this change, but it would not be
able to compile against it.

People complained stuff no longer builds.
>
>
> https://bitbucket.org/multicoreware/x265/commits/ce96cdb390fe26aee6effa731e51303c1d9056b0
>
> "Fixed" it in the worst possible way.
>
> It is not OK to re-purpose things like this, silently. It means code will
> keep
> compiling, but do the wrong thing.
>

I disagree; any program that used the old API can use the new one without
any change because before that commit internal and input bit depth were
always the same.  Both before and after that commit that particular field
has only served to validate that the user was aware of whether the library
was compiled for 16bpp or not.


> So please, bump the X265_BUILD number next time and no silently change
> behavior in the background, which was previously correct. It's not
> amateur hour.
>

Let's keep this polite.  I'll err on the side of bumping the build number
in the future.

-- 
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140218/947f1261/attachment.html>