On Mon, Jan 28, 2013 at 05:47:13PM +0100, Reinhard Tartler wrote:
> On Wed, Jan 9, 2013 at 5:32 PM, Thomas Goyne <[email protected]> wrote:
> > On Wed, 09 Jan 2013 01:48:15 -0800, Reinhard Tartler <[email protected]>
> > wrote:
> >
> >> Btw, this is because of the ffmpegsource drama, right? Does this patch
> >> actually help the ffmpegsource developers? I would be happy to include
> >> additional #defines if, and only if, that would help them.
> >
> >
> > Not particularly. In general we try to support every reasonably recent
> > released version, so it's too late to fix it now.
> >
> > Having 53.21.1 and 53.21.0 be significantly different versions is an
> > improvement over having two 51.21.0s, but it's still pretty terrible
> > since it ignores even the most basic parts of semantic versioning like
> > "bigger numbers come after smaller numbers".
> >
> > API version numbers are inherently not very compatible with making API
> > changes on multiple branches. One possible solution would be to have
> > separate non-sequential defines for each API change, so that they can be
> > reordered or cherry-picked willy-nilly. A simpler solution would be to
> > just not change the API in minor releases of stable versions, since
> > that's generally one of the main points of stable branches.
> 
> What has been done in this case is that ffmpegsource needed this
> specific API and decided to backport it themselves in a way that
> clashed the backport in the stable release branch (i.e., by using
> function names in the ff_*/ av_* namespace). Other options would have
> also been available, but that's not the point here.
> 
> >From this story, I do think that in some cases, API backports are
> called for, the challenge is that we need to provide a way to reliably
> check for their presence. And above all, to communicate/announce these
> changes more aggressively to avoid such an embarrassing drama.
> 
> We use FF_API functions to schedule deprecations/removals. Maybe we
> can also use them for backported APIs? If done properly, this would
> allow to significantly simplify the #ifdefery in ffmpegsource.

How would you use FF_API defines to solve the issue?

Diego
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to