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

[Dave Crossland]

Sure, but what concrete steps can we take to do that?

Adam blathering on about dropping CFF/CFF2 seems to be a much more
egregious "in passing" comment than what Li Renzhi said.... :)

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

> I think that if we want to introduce breaking changes we need to build the foundation for future discussions and consensus. Adam summed it up nicely in his previous email: explicit discussion, agreement, and also a benefit-cost analysis. (https://lists.aau.at/pipermail/mpeg-otspec/2020-September/002263.html)
>
>
>
> Vlad
>
>
>
>
>
> *From:* Dave Crossland <dcrossland at google.com>
> *Sent:* Friday, September 11, 2020 4:58 PM
> *To:* Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>
> *Cc:* Renzhi Li <Renzhi.Li at microsoft.com>; mpeg-otspec <
> mpeg-otspec at lists.aau.at>
> *Subject:* Re: Introducing breaking changes into the spec (was: RE:
> [MPEG-OTSPEC] [EXTERNAL] Proposal to deprecate derived search values)
>
>
>
>
>
>
>
> 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/ffc1f056/attachment.html>