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

[James Almer]

On 1/2/2016 1:16 PM, Andreas Cadhalpun wrote:
> On 02.01.2016 17:12, James Almer wrote:
>> On 1/2/2016 8:42 AM, Andreas Cadhalpun wrote:
>>> On 01.01.2016 15:19, Michael Niedermayer wrote:
>>>> Its a while since 2.8 so unless there are objections i will make a
>>>> 2.9 or if people prefer a 3.0 within the next month or so
>>>
>>> I think using 3.0 would better due to the backwards incompatible
>>> API changes.
>>>
>>> We should do this always to give the major version a defined meaning.
>>> That way we would use semantic versioning[1].
>>
>> We didn't for 2.4, which also had a project wide major bump.
> 
> Yes, but I think it would have been better.
> 
>> And really,
>> those who care about ABI breaks (distros) and library versions (distros
>> and API users) don't care about the arbitrary version of the ffmpeg
>> package as a whole.
>>
>> 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.
But that one at least would be for a reason the end user will actually
notice.

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