[FFmpeg-devel] FFmpeg 1.0

[Stefano Sabatini]

On date Tuesday 2012-10-02 22:00:34 -0300, jamal encoded:
> 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.

I like it.

What I don't like is the arbitrary use of the major number for
non-technical purposes, so that the next version number becomes a
subjective thing (I like 2.0, no I want 1.1, etc.).

Of course if we can assign a technical meaning to major and stick with
a deterministic scheme, while conveying useful info to the user
(e.g. related to backward-compatibility), I'm all for it.

Incidentally, we *did* break compatibility since 0.11 so the major
bump was retrospectively correct from this point of view.

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

I don't know how are they doing and why, but well version numbers are
just numbers, it's not like you risk to run out of them and overflow
unless you release every few seconds ;-).