[FFmpeg-devel] [PATCH] Explicitely declare {dst, src}Format sws_get*Context() params as enum PixelFormat

[Michael Niedermayer]

On Wed, Feb 11, 2009 at 10:28:05PM +0100, Stefano Sabatini wrote:
> On date Tuesday 2009-02-10 01:57:36 +0100, Michael Niedermayer encoded:
> > On Tue, Feb 10, 2009 at 12:04:11AM +0100, Stefano Sabatini wrote:
> > > On date Monday 2009-02-09 19:22:23 +0100, Michael Niedermayer encoded:
> > > > On Mon, Feb 09, 2009 at 06:10:41PM +0100, Stefano Sabatini wrote:
> > > > > On date Monday 2009-02-09 17:55:29 +0100, Diego Biurrun encoded:
> > > > > > On Mon, Feb 09, 2009 at 05:48:46PM +0100, Stefano Sabatini wrote:
> > > > > > > On date Monday 2009-02-09 09:27:35 +0100, Stefano Sabatini encoded:
> > > > > > > > On date Sunday 2009-02-08 21:48:25 -0800, Art Clarke encoded:
> > > > > > > > > On Sun, Feb 8, 2009 at 3:00 PM, Stefano Sabatini
> > > > > > > > > <stefano.sabatini-lala at poste.it> wrote:
> > > > > > > > > >> I wonder if I should bump micro/minor, maybe there are some
> > > > > > > > > >> compatibility issues with some compilers...
> > > > > > > > > >
> > > > > > > > > > Applied.
> > > > > > > > > 
> > > > > > > > > A little late now, but you should at least bump minor;  This breaks
> > > > > > > > > code for swscale users who previously passed in int values (like, oh,
> > > > > > > > > us).
> > > > > > > > > 
> > > > > > > > > We ran into the problem because we wanted to disguise the PixelFormat
> > > > > > > > > dependency in other objects and hence pass-around an opaque int; we
> > > > > > > > > just didn't cast it when passing back into SWSContext calls because we
> > > > > > > > > didn't have to (until this morning when our builds started breaking).
> > > > > > > > > 
> > > > > > > > > It's a simple fix in users' code, but I think it is an API change
> > > > > > > > > (yes, for the better, but a change none the less).
> > > > > > > > 
> > > > > > > > So we maybe should revert it, since it breaks compatibility. If
> > > > > > > > someone care feel free to do it, then I'll provide a backward
> > > > > > > > compatible change (#if version < ...) this night.
> > > > > > > 
> > > > > > > OK to revert or there are better ideas?
> > > > > > 
> > > > > > If Art can live with the version bump I think reverting is not necessary.
> > > > > 
> > > > > It's not only Art, all other users could update and get compilation
> > > > > broken.
> > > > 
> > > > so if i configure gcc to error out on a comment that contains "teh"
> > > > then we will consider adding such typo requireing a bump?
> > > 
> > > Uh? Sorry my zen is a little rusty ;-).
> > > 
> > > Do you mean that it was a bug in the first place, so using int rather
> > > than enum PixelFormat is/was to be considered an user error?
> > 
> > iam saying that it should work fine with int and enum and its the users
> > odd things that he did (using a private enum?) that broke it
> 
> Art explained the scenario when such a change caused a breakage, well
> they indeed did a rather dangerous thing and I consider after all the
> definition/declaration discrepancy we had before a bug on our side.
> 
> >From the technical point of view we may consider it:
> 1) a non-backward compatible change, thus requiring a major bump
> 
> 2) a bug fix on our side which fixed a previously (mildly) broken API,
> in this case it should be safe to just bump micro.
> 
> Minor bumps should be performed when introducing new symbols, for
> example introducing a sws_getContext2(), which would be totally
> screaming overkill for such a scenario.
> 
> I think everyone would agree that choice 1) is plain overkill as well,
> while I think 2) is quite tolerable.
> 
> So I propose these two choices to the maintainer, which are:
> 
> 1) bump micro

ok

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090212/8fbe1827/attachment.pgp>