Re: Release numbering

[Phil Edwards <phil at codesourcery dot com>]

Consider this, friends:

Occasionally one of us developers has made a suggestion that many other
people like, but is just too large a change.  Throwing out specs for
something simpler, using caret diagnostics by default, running daemonized
versions of tools; these are just three I can remember off the top of
my head.  Dozens have been proposed over the years.  

These tend to not happen for a lot of reasons, but maintaining compatability
is usually the most important of those reasons.  Users expect to be able to
replace/augment specs with 3.x; users of emacs and wily and heaven knows
how many other tools which parse our error messages expect that random
punctuation like carets to not appear; users don't expect the compiler to
stay resident in memory without being told to do so.

Users expect 3.(x+1) to behave mostly the same as 3.x did.  They will be
surprised if there are major changes.

Users will expect 4.1 to behave much the same as 4.0, and they'll expect
4.2 to be like 4.1 but with improvements, etc.  They will be surprised if
there are major changes.

Users will not expect a 4.0 release to behave like a 3.x release.
I'm certainly not saying it /shouldn't/ behave the same; there's no need
to gratuitously make thihgs different.  But users will not be surprised if
they differ.  They expect to conditionalize their scripts and makefiles
and other programs on major version numbers of /any/ tool, and GCC is
viewed no differently.  That's an opportunity we should not discard.

Here's my point:

    We need to hold the 4.0 label in reserve for Big Incompatible Changes.
    Not just "user-visible" ones, although they clearly would play a part.
    But any change where the users /must/ know whether 3.x or 4.x is in
    use before they (or their tools) can get much farther, /those/ are
    what we should wait for before changing the major version.

The 3.5 code is supposed to be starting to stabilize for release.  Now is
clearly not the time to, for example, completely change the formatting
of our diagnostic output.  But if we release 3.5 as 4.0, then the Big
Incompatible Changes are going to have to wait until 5.0 to go in.


Phil

-- 
"This release is mostly intended to mop up the minor and trivial bug fixes
in the list and clear out the documentation changes.  As such, it should be
treated with even more suspicion than is normal."
    - dpkg 1.10.22 release note