[FFmpeg-devel] Releases 1.1 2.0 1.0.1 ?

[Peter Ross]

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').

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121205/0d1a62e2/attachment.asc>