[FFmpeg-devel] 2.9/3.0, 2.8.5, ...

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Sat Jan 2 22:30:40 CET 2016


On 02.01.2016 21:03, James Almer wrote:
> On 1/2/2016 1:16 PM, Andreas Cadhalpun wrote:
>> On 02.01.2016 17:12, James Almer wrote:
>>> Some time ago it was argued that the ffmpeg version should for example
>>> get a major bump when some considerable changes were made to the CLI
>>> tools. Users that download ffmpeg and don't care about the libraries
>>> look at that version, and they are the ones affected by all and any
>>> changes made to command line options for those tools.
>>
>> But this is a quite arbitrary thing, as the command line interface
>> has lots of changes in every version.
> 
> As arbitrary as bumping major of the ffmpeg package for any other reason.

That's not what I meant. Sure, choosing a criterion (or not doing that)
is quite arbitrary. But the criterion itself can be arbitrary or not.
There can't be a reasonable disagreement whether or not a SOVERSION
was bumped, but on the other hand it's quite subjective what change
in the CLI tools is significant enough to warrant a new major version.

> But that one at least would be for a reason the end user will actually
> notice.

Which of the previous versions do you think would qualify for this
criterion?

I honestly don't think that's an easy question to answer.

>>> Personally I'd call this one 2.9, and then the next can be 3.0 instead
>>> of 2.10.
>>
>> That way the major version has no meaning at all.
> 
> Then go with 3.0. I don't care much, but I also don't think library
> major version bumps should always mean a bump for the ffmpeg package
> version.

We don't have to make it an absolute rule.
Let's use 3.0 this time and discuss again next time.

> Especially knowing a library may get a bump alone and not as
> part of a project wide bump like the one we made a few months ago or
> in 2014.

Yes, you have a point here. A SOVERSION bump in libavfilter has less
impact than one in libavcodec/libavformat/libavutil.

> Big API changes are IMO a better reason to bump ffmpeg major version
> than library major bumps that could happen with something as simple as
> moving a function or table from one library to another.

OK. However, big API changes usually involve a SOVERSION bump at some
point, don't they?

Best regards,
Andreas



More information about the ffmpeg-devel mailing list