Re: Beyond GCC 3.0

[dewar at gnat dot com]

Robert says

<<In an ideal world from a customer point of view there would be a
predictable gcc release cycle which produces "major" releases every 12
to 14 month. In these "major" releases anything goes, new features,
feature deprecation, feature use changes, etc. Within the 12 to 14 month
between "major" releases there should be 3 - 4 bug fix releases. These         
>>



Yes, for commercial use on a large scale, you do not want frequent releases
that change features, and I would assume that anyone getting commercial support
for gcc would ensure that the support vendor has an appropriate support policy
for their needs.

But the publically available development system at gnu.org has to meet a
far wider range of needs and goals. The stability requirements from large
commercial customers most certainly stifle rapid innovation, and in that
context, that is appropriate. But for the shared open development of gcc,
it is much more important to encourage innovation and technical advances,
so a more rapid release cycle, with greater tolerance for upwards
incompatibility resulting from desirable changes, is appropriate.

I would assume that any commercial support organization will provide 
their customers with what they need (indeed in some environments, changing
compilers even once a year is out of the question, and long term support is
required for baselined compilers). It is up to them to work out how to 
provide for their customer requirements, and how to interact with the release
cycle of the public gcc versions.

Certainly a customer with a large commercial application with millions of
lines of code is likely in any case to require formally supported software
(most large companies have, very resaonably, policies to that effect).

So for me, it is a mistake to hamper the gcc development with the slow
release cycle appropriate to such environments.

In the case of GNAT, it has often been the case that there are public versions
around with "more advanced" features, that for one reason or another were not
ready for incorporation into the commercially suported release. For example,
the volunteer group working on GNAT for GNU/Linux provbided RPM's long before
they were available in the commercial version. Why the delay? Because there 
were some subtle problems that could have affected large commercial users, but
were unlikely to affect most of the use of the public GNU/Linux version, e.g. by
students. 

Robert Dewar