[Ffmpeg-cvslog] CVS: ffmpeg/libavcodec avcodec.h, 1.435, 1.436 utils.c, 1.167, 1.168 mpegvideo.c, 1.499, 1.500

[Michael Niedermayer]

Hi

On Mon, Dec 26, 2005 at 09:57:36PM +0100, Alexander Strasser wrote:
> Hi,
> 
> Michael Niedermayer wrote:
> > On Mon, Dec 26, 2005 at 10:34:45AM +0100, Alexander Strasser wrote:
> > [...]
> > >   As I asked before, I am not clear about the second part
> > > adding a new function to the API should be API compatible,
> > > and ABI compatible too, so changing the second component is
> > > meant to be ABI compatible?
> > 
> > yes unless theres some issue iam not aware of ...
> 
>   Ok. This means second and third component are the same
> regarding to API and ABI compatibility, so they only
> have the informational difference that the second number
> means feature addition while the third means bug fix, right?

hmm, an application which works with 1.2.3 should work with 1.2.2 but
might not work with 1.1.3 at least that was the idea ...

[...]

>   Also the second component could/should/must be changed
> if I add a new API function, Coder/Decoder/Muxer/Demuxer,
> a new AVOption? The question is if it should be a strict
> or loose policy, one also might question what it is worth
> having a loose version policy.

new API function, field in a struct or struct which is part of the external
API -> increase second component (or first if the size change of a struct 
breaks somethig)
changes to available Codecs, Muxers or Parameters increase third unless
the change changes meaning/scale or such of a parameter then you would
have to increase the first :)

an argument why changes to available codecs and muxers shouldnt 
increase the first/second components is that codecs migh be disabled at
compiletime by the user or package maintainer


>   I think my documentation improves the current situation
> a little. 

yes


> But it might be worth it to start a new discussion
> on ffmpeg-devel 

yes, maybe


> and add the conclusion into a separate section
> of the developer documentation and refer to that section from
> the CVS Policy section.

yes


> 
>   Or did i understand something fundamentally wrong now?
> 
> > >   If so i should mention that explicitly for clarity.
> > > 
> > >   Also my previous argumentation was flawed because of
> > > me not taking into account that AVOption solves the
> > > problems with the many ABI incompatible changes.
> > > 
> > >   Also could it be that your answer to that part of my
> > > mail vanished somehow? 
> > 
> > no
> > 
> > > You normally write [...] if you
> > > skip parts.
> > 
> > hmm, if theres no [...] on your side then it vanished
> > 
> > [...]
> 
>   Oh, I just saw it was in the original mail. I must have
> accidently deleted it while writing the answer. Sorry for
> the trouble.

no problem at all, better to ask then to miss some typos by the CIA/KGB guys
who edit all my outgoing and incoming mails

[...]

-- 
Michael