[FFmpeg-devel] Releases 1.1 2.0 1.0.1 ?

[Alexander Strasser]

Hello,

  I know I am a bit late on this. Though there haven't been more
replies on this anyway...

Peter Ross wrote:
> On Tue, Dec 04, 2012 at 10:51:34PM +0100, Stefano Sabatini wrote:
> > 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
> > > otherwise
> > > 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
> > > user
> > 
> > > 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
> > rationale.
> > 
> > Others conditions to consider are:
> > - tool backward compatibility break
> > - API break (well we technically break it , considering the deprecated
> >   functions removal)
> 
> The major version of each library already informs "library users" of a
> not-backwards compatible change.
> 
> > 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).
> 
> I think the major version of the project should be *more* symbolic
> to the "end users" of FFmpeg, namely a tool backwards compatibility break,
> or significant feature change ('FFmpeg now supports vector image formats').

  I am in favour of handling it like Peter described. Makes a lot of
sense IMHO.

  Alexander