[Compat Data] Data Store API: Browser version status

[Jeremie Patonnier]

Hi!

This is the second follow up e-mail from my meeting with John last Friday

This one is about the Browser-versions status:

I'm concerned about the status attribute of the *Browser-versions*
collection.

-
https://github.com/jwhitlock/web-platform-compat/blob/master/api.md#browser-versions

How should it be maintain? If it must be maintain by hand (contributed), it
will be a nightmare and will never be done, especially for browser like
Firefox or Chrome which deliver a new browser every 6 weeks. Moreover, I
don't see the necessity to maintain such information in our DB, this should
be just software logic to determine which version is what and should not be
maintain at the DB level. Especially as we have no idea on how the Browser
market will evolved in terme of release policy (the rapid release cycle
introduce by Chrome was quite a choc on the market, we cannot predict if
the mobile market will not evolve as well one way or another in the next
years).

As such information could be quite important, I can be mistaken.
Especially, I do not realized how hard it could be to maintain such
information at the software level. Such information is one of the reason
"Can I Use" succeed so we will need to display one way or another. SO the
question is: where to handle such information?

Best,
--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>

[John Whitlock]

Jeremie,

Here's how I saw the workflow for maintaining the status of future Mozilla
versions:

1. Mozilla publishes the planned release date for a future version [1]
2. The MDN team decides it is worth documenting the upcoming release [2]
3. They add a new browser-version (browser=Mozilla, version=32,
release-day=Sept 1 2014, status=future)
4. They change support from 'no' to the new version in selected Browser
Compatibility Tables (BCTs) [3]
5. When the browser is released, they update the page to reflect that the
browser was released. [4]
6. They also update the data store to update the release-day and the
status. All the BCTs are updated to show the version is a current version.

[1] https://wiki.mozilla.org/Releases
[2] https://developer.mozilla.org/en-US/Firefox/Releases/32
[3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/track
[4] https://developer.mozilla.org/en-US/Firefox/Releases/31

Steps 1, 2, 4 and 5 are already part of the work flow. Steps 3 and 6 will
require additional features to make it straightforward for contributors.
I'd support leaving out beta versions, like the one on the tab-size page:

https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size#Specifications

This doesn't seem like a nightmare. What am I misunderstanding about the
process?

John

[Jeremie Patonnier]

Hi!

Two things

1. This is currently done at a software level (through KumaScript (which is
good IMO). I still don't see the need to keep such a volatile piece of
information within the data base.

2. It's quite easy to do this for Mozilla products as the MDN team can
easily access to such information. If we want to do this for all browsers,
that's another story. For example, what about a simple case: Safari 8 and
Internet Explorer 12? They will be released, we know that for sure, but
what is their current status? It's not "beta" nor "released". We also have
no idea of their future release date. But beside that we already have
official information about the features they will support and we want to
document them. And I do not talk about the mobile world, which is even
worst.

[Ali Spivak]

wouldn't it be possible to have release date: TBD and then still use the rest of the information? Of course, it would require going in and updating with the actual release date, but that should be possible....





ali spivak
Manager, MDN Content & Community
408-859-8260
asp...@mozilla.com

----- Original Message -----

<blockquote>

Hi!

This is the second follow up e-mail from my meeting with John last Friday

This one is about the Browser-versions status:

I'm concerned about the status attribute of the Browser-versions collection.


* https://github.com/jwhitlock/web-platform-compat/blob/master/api.md#browser-versions

How should it be maintain? If it must be maintain by hand (contributed), it will be a nightmare and will never be done, especially for browser like Firefox or Chrome which deliver a new browser every 6 weeks. Moreover, I don't see the necessity to maintain such information in our DB, this should be just software logic to determine which version is what and should not be maintain at the DB level. Especially as we have no idea on how the Browser market will evolved in terme of release policy (the rapid release cycle introduce by Chrome was quite a choc on the market, we cannot predict if the mobile market will not evolve as well one way or another in the next years).

As such information could be quite important, I can be mistaken. Especially, I do not realized how hard it could be to maintain such information at the software level. Such information is one of the reason "Can I Use" succeed so we will need to display one way or another. SO the question is: where to handle such information?

Best,
--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @ JeremiePat

</blockquote>

[John Whitlock]

Yes, release date could be optional, and displayed as 'TBD' for future
releases. For current releases, it could be 'Unknown' or 'Released on some
date in the past', like MozillaWiki displays:

https://wiki.mozilla.org/Releases#Based_on_Gecko_31

I was aggressively moving stuff from KumaScript to the database. What is
your opinion on the other items, such as all the specification stuff?

https://developer.mozilla.org/en-US/docs/Template:SpecName
https://github.com/jwhitlock/web-platform-compat/blob/master/api.md#specifications
https://github.com/jwhitlock/web-platform-compat/blob/master/api.md#specification-sections
https://github.com/jwhitlock/web-platform-compat/blob/master/api.md#specification-statuses
https://developer.mozilla.org/en-US/docs/Template:Spec2

On Tue, Jul 22, 2014 at 11:01 AM, Ali Spivak <asp...@mozilla.com> wrote:

> wouldn't it be possible to have release date: TBD and then still use the
> rest of the information? Of course, it would require going in and updating
> with the actual release date, but that should be possible....
>
>
>
>
>
> ali spivak
> Manager, MDN Content & Community
> 408-859-8260
> asp...@mozilla.com
>

> ------------------------------
> *From: *"Jeremie Patonnier" <jeremie....@gmail.com>
> *To: *"John Whitlock" <jo...@factorialfive.com>
> *Cc: *dev...@lists.mozilla.org, "Luke Crouch" <lcr...@mozilla.com>,
> "Alicia Spivak" <asp...@mozilla.com>
> *Sent: *Tuesday, July 22, 2014 8:56:22 AM
> *Subject: *Re: [Compat Data] Data Store API: Browser version status

>>> I'm concerned about the status attribute of the *Browser-versions*
>>> collection.
>>>
>>> -

>>> https://github.com/jwhitlock/web-platform-compat/blob/master/api.md#browser-versions
>>>
>>> How should it be maintain? If it must be maintain by hand (contributed),
>>> it will be a nightmare and will never be done, especially for browser like
>>> Firefox or Chrome which deliver a new browser every 6 weeks. Moreover, I
>>> don't see the necessity to maintain such information in our DB, this should
>>> be just software logic to determine which version is what and should not be
>>> maintain at the DB level. Especially as we have no idea on how the Browser
>>> market will evolved in terme of release policy (the rapid release cycle
>>> introduce by Chrome was quite a choc on the market, we cannot predict if
>>> the mobile market will not evolve as well one way or another in the next
>>> years).
>>>
>>> As such information could be quite important, I can be mistaken.
>>> Especially, I do not realized how hard it could be to maintain such
>>> information at the software level. Such information is one of the reason
>>> "Can I Use" succeed so we will need to display one way or another. SO the
>>> question is: where to handle such information?
>>>
>>> Best,
>>> --
>>> Jeremie
>>> .............................
>>> Web : http://jeremie.patonnier.net

>>> Twitter : @JeremiePat <http://twitter.com/JeremiePat>

>>>
>>
>>
>
>
> --
> Jeremie
> .............................
> Web : http://jeremie.patonnier.net

> Twitter : @JeremiePat <http://twitter.com/JeremiePat>
>
>

[Jeremie Patonnier]

+Teoli as he's some sort of our spec gatekeeper :)

2014-07-22 18:04 GMT+02:00 John Whitlock <jo...@factorialfive.com>:

> I was aggressively moving stuff from KumaScript to the database.
>

I'm basically kind of okay with that approach when it comes to stable data.

> What is your opinion on the other items, such as all the specification
> stuff?
>
> https://developer.mozilla.org/en-US/docs/Template:SpecName
>
> https://github.com/jwhitlock/web-platform-compat/blob/master/api.md#specifications
>
> https://github.com/jwhitlock/web-platform-compat/blob/master/api.md#specification-sections
>
> https://github.com/jwhitlock/web-platform-compat/blob/master/api.md#specification-statuses
> https://developer.mozilla.org/en-US/docs/Template:Spec2
>

I'm okay with the specification and specification-statues structures (Even
if the kuma-key is not really necessary because I think the glue between
kumascript and the DB specification id should be handled at the kumascript
level, outside of this context, such data as no meaning therefor I don't
think it's necessary to keep it at the DB level: Remind that it is intended
to open that DB to the outside).

That said, I do not understand the necessity to the specification-sections
structures (especially as it is something that can change quite a lot as
long as the specification is not in its final state). I don't see why it
should be stored into the DB. I should miss a use case here. Teoli, any
thought on this?

At an API level, I think we should not expose specification-section
independently and always provide a view which aggregate specification and
specification-section (and in write mode, transaction to unconstructe the
view or keep it as it is if our backend is an indexed DB). This is because
a specification-section cannot be shared between several specification.

[John Whitlock]

My intent was to deprecate all the Spec* and Compat* scripts, and replace
them with database lookups. kuma-key was an aid for transitioning from
wiki-versioned tables to API-based tables. After a page was transitioned,
the tables would be replaced by something like:

{{CompatLoadFeatureSet('css-display')}}

<h2 id="Specifications" name="Specifications">Specifications</h2>
{{SpecTableForFeatureSet('css-display')}}

<h2 id="Browser_Compatibility" name="Browser_Compatibility">Browser
compatibiity</h2>
{{CompatTableForFeatureSet('css-display')}}

specification-sections supports the current pattern - a feature is
specified in a section of a specification. The same feature may be
specified in other sections of other specifications as well. You might be
able to derive interesting information as well, such as following the
evolution of a feature across specifications, or viewing the support for a
specification across browsers.

[John Whitlock]

At Luke's request, I've convert the docs to RST.

Rendered versions can be found at:

http://web-platform-compat.readthedocs.org/en/latest/index.html
http://web-platform-compat.readthedocs.org/en/latest/draft/resources.html#browser-versions

and the RST source at:

https://github.com/jwhitlock/web-platform-compat/tree/master/docs/draft



On Tue, Jul 22, 2014 at 12:21 PM, John Whitlock <jo...@factorialfive.com>
wrote: