[FFmpeg-devel] FFmpeg 1.0

jamal jamrial at gmail.com
Wed Oct 3 03:00:34 CEST 2012

On 02/10/12 9:03 PM, Ivan Kalvachev wrote:
> On 9/30/12, Stefano Sabatini <stefasab at gmail.com> wrote:
>> On date Friday 2012-09-28 04:24:03 +0200, Michael Niedermayer encoded:
>>> Hi
>>> FFmpeg 1.0 release uploaded & download page updated, ill update the
>>> front page after a bit of sleep
>>> iam planing to release 1.0.1 in 2 weeks, if you want some changes in
>>> it, create a branch based on the release/1.0 branch in your public git
>>> repo and cherry pick everything you want in the release
>>> in that branch. than just ask me to merge it.
>>> thanks
>> BTW, I'd propose to follow a more linear approach for releases
>> numbering, and just use two version numbers major.minor and discard
>> micro.
>> For example we could next release a branch 2, with the tags 2.0, 2.1,
>> etc.
>> This should also clarify things for users.
>> --
> So following the Chrome/Firefox example,
> instead of the kernel version scheme.
> IMHO, the switch would be more confusing for the users.

Firefox does mayor (actual releases) and micro (bug/security fixes) versions only.
15, 15.0.1, 16, etc.

I'd rather keep the ffmpeg numbering scheme as it has been until now (Kernel-like). But if we end up changing it, what about bumping the mayor only when one or more libraries also get a mayor version bump, or when a new library or application gets introduced/removed?
As in, let the next release from a given branch bump micro, and then new branches released every 3 to 6 months bump minor, unless a library got a mayor bump or a new library/application got introduced/removed in which case the new branch would bump mayor instead.

Whatever we do, lets try to not have a mayor bump fest. Chrome/Firefox version schemes are IMO ridiculous.


More information about the ffmpeg-devel mailing list