[FFmpeg-devel] Releases 1.1 2.0 1.0.1 ?
stefasab at gmail.com
Tue Dec 4 22:51:34 CET 2012
On date Tuesday 2012-12-04 16:55:52 +0100, Michael Niedermayer encoded:
> On Tue, Dec 04, 2012 at 12:26:31AM +0100, Stefano Sabatini wrote:
> > The questions are:
> > - do we want to use major to indicate *binary backward compatibility*,
> > as it was proposed some time ago?
> > - did we break backward compatibility with the 1.0 release?
> > The answer to the second question seems to be yes, since we bumped
> > libavutil after the 1.0 release, even if possibly not many users will
> > notice it. Releasing 2.0 just after 1.0 seems not very glamour, but at
> > least conveys this information (which is very valuable to the user).
> In which way is it valuable ?
> the command line interface did not change, the user may expect
> the API did not change, the user may expect otherwise
> what changed is the removial of a few deprecated functions from
> libavutil, this no doubt needs libavutil major to bump but defining
> ffmpegs major release number this way is IMHO not valuable for the
> not saying here we should favor either 1.1 or 2.0 just that this
> strict definition would lead to random numbering more than usefull
> numbering. There easy could be a 5.6 -> 5.7 that adds ten times more
> chnages than a 5.0 -> 6.0 just because someone decided to bump some
> libs major in the later case
I don't mind what criteria we adopt to mark a major release bump,
provided it is reasonable and it is possibly based on a technical
Others conditions to consider are:
- tool backward compatibility break
- API break (well we technically break it , considering the deprecated
the more exact the definition is, the better it is, so we avoid this
discussion at every release. That said, I happily leave the final
choice to who is doing the real work (you in this case).
FFmpeg = Fabulous and Fierce Mystic Practical Extroverse Governor
More information about the ffmpeg-devel