This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Beyond GCC 3.0: Summing Up


In article <20010711012329.9672AF2B5C@nile.gnat.com> you write:
>You guess wrong, we do of course provide support for older versions (the
>standard policy, easily extended on special deals) is to support versions
>for one year after the new version comes out. But people still don't like
>frequent releases because it creates pressure for them to consider upgrades,
>and they feel like they should be the most recent version. (people = some
>subset of people, others are fine with a six month release cycle).

There is an important point that hasn't been mentionned already:
other projects also have release cycles. Especially vendors.
Now, for each vendor, there is a point in the cycle where they can't afford
a new gcc release. This might depend on the vendor, but if they want
stability, at some point, they either must stick with the previous release,
or delay their own release for a bit. The alternative---having gcc synchronize
with one specific vendor cycle---is quite simply unthinkable. I would probably
be the first to cry murder and petition for equal treatment if any Linux
distribution were to get this kind of preferential treatment.

If gcc has infrequent releases, this is an annoying problem: the gap between
3 years-separated releases is large, and highly noticeable... it might
cause problems, loss of revenues to vendors, and they might even cut
corners to try to alleviate those problems.

With a frequent schedule, those problems more or less disappear. The
perceived improvement between two successive releases is less, and the 
vendors can concentrate on getting out robust products without too much
consumer pressure (unless they specialize in all-new, all-shiny, all-alpha
software, like some linux distributions do). That is to say: with a six months
release schedule, if a gcc release comes out two days too late for a given
vendor shipping process, they can very well afford to not upgrade and proceed
with their release, because the previous release will be perceived as fairly
good already...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]