Re: Minutes for the 2017-06-21 meeting

I agree that while we are updating the prototype and MVP, we should keep a
clear list of incompatible changes to help early adopters update their code
(or even a regexp). However once the 1.0 is released, we need to stay
backwards compatible as much as possible, so extra functionality could be
exposed as extensions. Fixes for stability and security would still need to
go in. As far as I know it is a myth that WebGL code broke because of such
fixes: all the original WebGL demos still work.

On Fri, Jun 23, 2017 at 4:52 AM, Stephen White <steve@adam.com.au> wrote:

> On 23 Jun 2017, at 5:36 am, Corentin Wallez <cwallez@google.com> wrote:
> >       • CM: The first one is the most simple thing we could do. Why not
> start with that?
> >       • JG: How much change are we willing to change between MVP and the
> final product?
> >       • BC: we can tolerate a loarge amount of change between MVP and
> version 1.0. Much less between 1 and 1.1(?).
>
> This was the point behind the issue I raised on Github. If you release the
> simplest API then find you need to change it, there should at least be a
> very simple check and fill in if the API changes.
>
> It could almost be a “if API > 1.0, regexp these bits of code” for a
> common case, and if it doesn’t work then too bad, but it’s better than the
> WebGL experience of all older code breaking.
>
> --
>   steve@adam.com.au
>
>