Criteria for GCC 4.0

[Theodore Papadopoulo]

The mere fact that this number topic is so discussed means that 
something is missing in the current release numbering scheme.

abraham@dina.kvl.dk said:
> If we never have a 4.0 release, then the major version number is
> redundant, and can be optimized away for space.  The next version will
> then be GCC 5 (short for GCC 3.5).  5.x will be bug-fix only releases,
> and the next release with new features will be 6.

If a major number is never useful, one might argue that then the 
rules are too stringent...

On the other hand, one expects the major number not to change too often.
I tend to believe that major numbers should be kept stable for at least
6--10 years, and have at least around 10 releases in between. Changing those
more often tend to give the impression of an unstable product, never changing
it gives the impression (wrong sure) that nothing changes...

Another problem is users' perception. Bumping major number is 
interpreted in different manners (user perception may vary from one 
product to an another):

- Some people consider x.0 releases as unstable and not usable.
- Other consider that it is the first "usable" release (not 
  yet extremely stable, but enough to work for most people). Usually, 
  this perception happens with products that had a long x.99 or beta 
  history (but note that despite several test-release candidates, 
  no one trusted the 2.6.0 linux kernel to base a distribution upon 
  it).

These numbers are also for communicating with users.
The rank (major, minor, etc..) of the number change should somehow 
show the troubles of doing an upgrade for user joe (not through
upgrading a full (eg linux) distribution).

Assumption: the version number is  major.minor.sub.

There are (at least) 5 types of events that need to be communicated 
to users (Joe users not distrib managers):

   1 Upgrade is simple and brain-less, right now sub is changed and I 
     think everyone is happy with that rule.

   2 Upgrade is not too difficult contains some differences but those
     are basically small, and upgrading/recompiling you own code is 
     estimated to be in the range of a week (put your own limit here, 
     week is just an indication) on average for one 
     developer (big codes usually have more than one developer).
     It is OK to remove obsolete ports (does not have effects on the
     average), change flags, frontend syntax, etc...
     Again, the rule adopted by GCC for this case seems appropriate, 
     and no-one complains.

   3 Upgrade is difficult (ABI break, major language change, ...).
     But expected quality (whatever that means) still increases 
     monotonically.

   4 Indicate that the quality may be (temporary) lower because a 
     major piece of development has been made and has not yet received
     the same level of testing as the rest of the code. Regressions
     (missing ports, missing languages, missing features, slower 
     compilations times, full redesigns, ...) are allowed.
     The release is made to obtain not for use in productions systems
     but for testing "in the large" purpose. These are the usual
     test-releases or alpha-beta releases... which gcc does not have.
     Importantly, this gives developers more time to polish the new 
     code. Complains of users about decreasing quality (speed of 
     compilation , size or speed of the code, ...) or stability
     can be registered  (and treated eventually) but waved with "this is still beta 
     code".

   5 Indicate that after a decrease of quality, the quality level is 
     now again to the level it was before the decrease.

GCC is doing 1 and 2 very well IMHO, 3 and 4 is unclear to me (basically 
all this 3.5/4.0 discussion is because situations 3 and 4 are not 
distinguished currently), and 5 simply does not exist.

Back to GCC:

As a standard user, I do not care so much about next version of gcc 
to be called 3.4.99.0 (the 99 indicating that it is a beta), 
3.5.beta.0 3.5 (test candidate 0) or 3.99.0 or even 4.beta.0 .
What I want is an indication of the risk I take in installing the
new compiler and using it.

----------------------------------------------------------------------
A way of sending all the 5 messages above (an possibly more) through
(extended) version numbers should be designed and published on the web 
and then used.
----------------------------------------------------------------------

The next version of GCC with its totally new fortran front-end, 
without ada, and with all the ssa work (all of high quality sure, but 
much less tested code) seems to fall in category 4 in the current 
state of the code and from what I get from reading this list...

Both the 3.5 and 4.0 camps seem to have reasonable arguments. But bumping 
to 4.0 now would preclude bumping the major number again soon and I 
do not know what is in preparation for the short future that would be 
more dramatic than the current change...

What is sure is that I want something that means "This version is somewhat
beta" now, and a message "This is as good (and even better) than 3.4.x was"
when ada will be integrated, f95 and ssa more tested, ....

Another problem is that the message is global for all languages, whereas 
their states are really different... One "beta" version for fortran 
might be a perfect release candidate for C/C++.

After having considered all this, my silly (and certainly stupid)
proposal would be:

3.5.test.0 and a version string containing also the information 
"(c/c++: ok, gfortran: beta, ada: missing)". The 3.5.test series 
end up when all the states for the supported languages become ok
and get the 3.5.0 version number. If 4.0 is the decided target for 
the version number, the same thing could be applied.

Practically, this basically also means that the normal rules for the test 
releases are somewhat relaxed and that for that cycle of development
3.5.test.x might have more radical changes than eg 3.5.x changes (new 
languages, new ports, bug corrections, ...).

My 0.0002 euros on the gcc version numbering issue....
Sorry for this very long E-mail...
 

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------