create an official definition of obsolete

[graingert]

[graingert]

Is it based on current vendor support? Is it based on usage patterns?

Does only premium enterprise support count as obsolete?

[kangax]

Thanks, good idea. We should have done this earlier. @webbedspace should know more on what we're doing now.

[ljharb]

Some reasonable options, from which we can select multiple:

• not the latest version
• not officially supported by the engine vendor
• not in wide usage

[graingert]

What about not officially supported vs only enterprise (paid) support?

[ljharb]

Any form of support imo qualifies as "officially supported", because it means there will exist some users who are using it with those expectations.

[webbedspace]

I don't have any strong opinions about defining non-obsolescence. The heuristics we've been using up to now have been these:

• The current stable version for auto-updating rapid-release browsers (Firefox and Chrome) with exception for Firefox Extended Support Release.
• Official MS support for the IE/Edge line.
• Apple support of particular OS X / iOS versions for the Safari line (though this may currently need updating).

There's no real heuristic for Node, however. Moreover, the ES5 and non-standard tables have been largely neglected w/r/t updating their browsers.

[ljharb]

(fwiw node still has official support of 0.10 and 0.12 through 2016)

[samsch]

As a user of the table, it would be useful if the previous stable versions were not dropped so quickly. For example, right now, Chrome 49 was just released, and is the current stable, but going by StatCounter (daily count), it doesn't even have as many users as Chrome 47, and 48 has barely started to decline. Firefox also suffers from this, as Firefox 45 is just released, but 44 is still the main version in use.

Perhaps a few weeks of overlap?

This isn't directly related, but it would also be nice to have the beta and alpha (Dev Edition) for Firefox back on the chart.

[chicoxyzzy]

We should document this and add to README.md / CONTRIBUTION.md

[graingert]

@chicoxyzzy a decision should be made first.

maybe remove the term "obsolete" and use "supported" and "unsupported"

where supported is clarified with "nb: IE support refers to support on Microsoft Windows desktop editions"

[chicoxyzzy]

maybe remove the term "obsolete" and use "supported" and "unsupported"

I agree. We should have supported and release date instead

[afmenez]

My proposal is to add two new fields on browser definition:

released: YYYY-MM-DD, // first release of this version retired: YYYY-MM-DD // when the vendor stops supporting this version

Then the build script could follow these rules:

• If "obsoleted:very" or retired>1 year past, don't show the browser at all;
• If "obsoleted:true" or retired is in the past, the browser is obsolete;
• If "unstable:true" or released is in the future, the browser is unstable;

[ljharb]

I don't think "time" is at all an accurate measurement of "obsoleteness".

[mgol]

I agree with @ljharb that time is not an accurate measurement of obsoleteness. That said, it would be tedious to continually debate whether some Chrome version stops being widely used every 6 weeks, the same for Firefox/Chrome. That's why, apart from the need to define obsoleteness, I think the project needs to settle on some conventions on how many last versions of quickly moving browsers it keeps by default. Something like "last 2 Chrome versions" or "last 3 Chrome versions" speaking in browserslist terms.

Of course, it may happen that a specific Chrome version remains in relatively wide usage even though it falls out of this "last n" pattern, e.g. because it's the last version supported on some Windows version. In such cases, there's the need to be able to decide that this specific version is not obsolete yet and then re-evaluate the decision sometime in the future. But there still needs to be a default of "last n versions" for these browsers to reduce discussion churn.

[ljharb]

For browsers that autoupdate aggressively, i agree with that.