[Ffmpeg-cvslog] CVS: ffmpeg/libavcodec avcodec.h, 1.435, 1.436 utils.c, 1.167, 1.168 mpegvideo.c, 1.499, 1.500
Tue Dec 27 00:33:45 CET 2005
Michael Niedermayer wrote:
> 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 ...
App working with 1.2.3 should work with 1.2.2 and 1.3.2 but
might not work with 1.1.3.
Ok, that was the bit i was missing somehow. Then I'll leave
it the way it is for now.
> > 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
This brings up the question of seeing libav as
the framework and the codecs and muxers as modules
with their own versioning. But i don't think it is time
for this yet and that therefore we should let even
codec/muxer changes change the first and second numbers
to be on the safe side.
> > I think my documentation improves the current situation
> > a little.
> > 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.
I think I'll merge the 3 points above and try to beat my
lazyness and write a `Version Policy' section for the developer
docs and send this patch then to ffmpeg-devel to revive the
> > > > 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
More information about the ffmpeg-cvslog