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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
