Re: Microsoft versioning proposal

On 4/18/07, Dannii <curiousdannii@gmail.com> wrote:
>
> On 4/19/07, Chris Wilson <Chris.Wilson@microsoft.com> wrote:
> >
> > "Freeze development" is not quite how I would put it.  "Freeze behavior"
> > is what I would say, and yes.
> >
> > We will always make security and crashing-bug fixes in our code, at
> > least within the limits of our maintenance contract (7 years from release, I
> > believe, is the brief semi-accurate version).  Once a mode becomes
> > significantly popular, we can't make big changes to already-existing
> > behavior.  Today, many of the changes we need to make are big, and cause
> > compatibility problems.  (I'll refer to the IE7 example of "we started
> > following how CSS says overflow is supposed to work, and loads of sites
> > started overlapping text".)
> >
> > We've already frozen behavior in quirks mode, as have other
> > browsers.  The mistake we made in IE7 was that "standards mode" was already
> > popular and depended, for us, on IE's incorrect behavior.
> >
>
> So because of your policy of freezing behaviour (I'd consider it freezing
> development, security and bug fixes is maintenance not development) you
> haven't actually fully implemented the CSS specs for example. Will you then
> try to fully implement all of the relevant W3C specs in IE8? Will that take
> such a long time that again people will complain that their pages are broken
> because they depend on an incomplete implementation?
>
> It seems to me that freezing behaviour and long release cycles has been
> proved to work badly. I'd prefer to see more frequent releases of IE, even
> up to every six months, releases that implement the specs in stages. If
> people understand that the few bugs will be fixed soon, they will be less
> likely to start depending on those bugs or serve IE different content.
> They'll start expecting IE to work as well as any other browser, which is
> something I think we all want.
>



Oh, please no. :)  Long release cycles are a very good thing, when it comes
to changing behavior.  Lots of frequent changes mean lots of
slightly-different browser versions in use.  Lots of slightly-different
behaviors mean the web application developer's work becomes much harder.

In fact much of the current wealth of new web applications is in part
enabled by the fact that Netscape 4 faded out, and IE (in the form of IE6)
was unchanged for so long.  Fewer differing targets mean the web developer
can spend more time being creative, and less time in testing.

Intermediate releases for security/crashing bug fixes can be frequent.
Releases with changes in behavior should be infrequent.

If your concern is with how closely IE-next implements HTML-next, if we want
all browser implementations to converge on a single common standard in as
few iterations as possible, then our collective interest lies in crafting an
as-best-we-can-make-it set of validation tests that all browser implementors
can use.

Strong validation tests are a boon.  Frequent releases of differing
implementations are a bane.