1160214 - [Compat Data] Support unknown future versions

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: General, enhancement)

Description

[John Whitlock [:jwhitlock]]

What problem would this feature solve?
======================================
The API supports announced feature support.  For example, Firefox 39 [1], planned for release in June 2015 (2 months from bug filing) will add support for <string> type on list-style-type [2].  This is marked as support=yes for a version with status=future and a null release date.  When Firefox 39 is released, that versions' status can be updated to 'current' and the release date set, with the modification cascading to the relevant displays.

However, there are some features where support is planned or in development, but the release version has not been assigned.  An example is <length> for tab-size [3], where a patch is being tracked in bug 943918.  Another example is support for Ambient Light Events [4], which are supported in Chromium but not Chrome [5], and where IE support is planned but the schedule is unknown.

Currently, the way to specify an unknown version is by setting the version = null, but this is more commonly used to specify features that have been supported for a long time, in an early version of the browser.  Re-using version=null could lead to confusion.

[1] https://developer.mozilla.org/en-US/Firefox/Releases/39
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-type#Browser_compatibility , <string> is last row
[3] https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size#Browser_compatibility
[4] https://status.modern.ie/ambientlightevents
[5] http://crbug.com/336424

Who has this problem?
=====================
Staff contributors to MDN

How do you know that the users identified above have this problem?
==================================================================
There are pages with this issue already on MDN (see links above).  fsholtz (in IRC conversation) said that a display like https://status.modern.ie for Firefox is a desired use case for API-backed data.

How are the users identified above solving this problem now?
============================================================
MDN tables usually include inline links to tickets or pages describing the current status of development.  This implies "not supported now but maybe soon".  Good enough for human-readable data, but not precise enough for the API, and hard to discover and update when they become planned feature or dropped features.

Do you have any suggestions for solving the problem? Please explain in detail.
==============================================================================
Use a new version string to identify features where the work has started but isn't in a planned release.  Some options are "in development" or "future".  When using this version string, only version.status = "future" will be allowed.  In a similar way version.version = null should restrict version.status to "current".

Is there anything else we should know?
======================================
Feature was discussed in #mdndev IRC room previous to bug filing.  This ticket includes all the details that I think were relevant, but davidwalsh, shobson, or fscholz may have more information.

Comment 1

[John Whitlock [:jwhitlock]]

Needs to also support "nightly" version, as seen in https://bugzilla.mozilla.org/show_bug.cgi?id=1170709

Comment 2

[John Whitlock [:jwhitlock]]

Here's a possible design for various "unknown version" scenarios.  Stephanie, can the UI support this?

"This feature is supported by the current release of this browser.  We don't know when it was added, but we wouldn't be surprised if it was in the first version".  This was version.version = null, and version.status = "unknown".  After this API change, this will be version.version = "current", and version.status = "current"

"This feature is planned for future version 99".  This is still represented with version.version = "99.0", version.status = "future".  When the version is released, the version.status can be updated to "current", and tables get auto-updated.

"This feature is supported in the nightly build of the browser, but hasn't been assigned to a planned release".  This will be represented as version.version = "nightly", and version.status = "beta".  When the feature is assigned to named version, the API can be updated by 1) creating a new support for the named version and deleting the nightly support, or 2) switching the associated version to the named version.

"This feature is supported in source code, but is off by default, and planned for a future version that isn't named yet".  This is represented with version.version = "future", version.status = "future".  When the feature is assigned to a named version, the API can be updated like the nightly version.

The compatibilty tables on MDN will show the support of features by the current shipping browsers, and users can click to see more information about future and beta versions.

This change will eliminate the version.version = null option.

Comment 3

[John Whitlock [:jwhitlock]]

After some discussion on IRC, it sounds like the rules should be:

1. If status == 'current', the version is 'current' or numerical
2. If status == 'future', the version is text ('nightly' for firefox, 'canary' for chrome)
3. If status is 'beta', 'retired beta', 'retired', or 'unknown', the version should be numerical
4. The version should not be updated, except by domain experts (it should act like a slug).

Some examples:
* version="current", status="current" - Used for the "(yes)" supports on features that have been supported forever, like <p> [1]
* version="40", status="beta" - Firefox 40 [2] is planned for the future, but can be downloaded and tried today.  When it ships, the status will update to "current"
* version="nightly", status="future" - Firefox Nightly contains in-development work that may be assigned to versions eventually

The combos of what is allowed and not allowed will be enforced by API, and creating new Versions should probably be restricted to experts / admins.

When a feature moves from nightly to a particular release, this is modeled in the API by changing the support.version from the nightly version to the "versioned" version.  In other words, the support changes, not the version.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/p
[2] https://developer.mozilla.org/en-US/Firefox/Releases/40

Comment 4

[John Whitlock [:jwhitlock]]

Changes submitted as PR #41:

https://github.com/mozilla/web-platform-compat/pull/41

http://browsercompat.herokuapp.com has been updates with the code.

Comment 5

[MDN Team (:mdn-dev)]

Commits pushed to master at https://github.com/mozilla/web-platform-compat

https://github.com/mozilla/web-platform-compat/commit/e6a75cc9bdc7db37870b7269f75d24e37e99b139
bug 1160214 - Convert empty versions to "current"

https://github.com/mozilla/web-platform-compat/commit/2d4c1df1b40cc10cd31f3ef44095746c5cb0e455
bug 1160214 - Disallow blank version.version

https://github.com/mozilla/web-platform-compat/commit/e6202286f37e0f62a86cb842cf89447ce9776d22
bug 1160214 - Validate status/version combination

For Version, both model and API validation check:

* version can not be blank
* For status "current", version is "current" or numeric
* For status "beta", "retired beta", "retired", and "unknown", version
must be numeric
* For status "future", version must be text

Update docs for new restrictions, and API examples using
`make docs-regen-api`

https://github.com/mozilla/web-platform-compat/commit/e20805638cc627e52585db071e922d506e355369
bug 1160214 - version/status integration tests

Add `make test-integration` tests for disallowed version/status
combinations.

https://github.com/mozilla/web-platform-compat/commit/121113d26783095c5c368f8b0d06343c5831ec22
fix bug 1160214 - Convert version to write-once

https://github.com/mozilla/web-platform-compat/commit/14525a41ab307adb6a5ad5857ab02d5b8d020c8c
Merge pull request #41 from jwhitlock/1160214_future_versions

Fix bug 1160214 and fix bug 1170709 - Support unnumbered future versions, {{CompatNightly}}