[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