[MPEG-OTSPEC] Introducing breaking changes into the spec (was: RE: [EXTERNAL] Proposal to deprecate derived search values)

[Dave Crossland]

On Fri, Sep 11, 2020 at 4:12 PM Levantovsky, Vladimir <
Vladimir.Levantovsky at monotype.com> wrote:

> I did NOT say they can’t happen here, but this is exactly the kind of
> decision that cannot be taken lightly, and it is definitely not a joke!
>

Thanks for clarifying - so you are saying, comments made about 1.X vs. 2.0
_are_ helpful and welcome here, but not "in passing"? If yes, how to
formalize such discussions? :)

On Github, we can have issues assigned to Milestones so its very clear what
context they are in:

1. Current Spec Changes (Editorial - no differences for implementations,
"OT 1.8.x)

1. Iterative Spec Changes (Small to medium work required by implementations
to meet the standard, "OT 1.9.x")

3. Incompatible Spec Changes (Large impact for implementations, "OT 2.0")



> New specs can be written easily, but it’s the wide adoption [not the spec
> itself] that we should care about the most because, in the end, it is what
> benefits users. You seem to care a lot about consensus decisions, and this
> is exactly why consensus decisions are so important.
>

Harfbuzz is now adopted widely (Google, Adobe, MS...) and anyone can fork
and implement anything and submit it mainly harfbuzz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200911/1b67a39b/attachment.html>