[FFmpeg-devel] FFmpeg 1.0

[jamal]

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.

Regards.