[FFmpeg-devel] Releases 1.1 2.0 1.0.1 ?
pross at xvid.org
Wed Dec 5 10:04:35 CET 2012
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
> 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').
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel