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

Levantovsky, Vladimir Vladimir.Levantovsky at monotype.com
Fri Sep 11 23:24:15 CEST 2020


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<mailto: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/bbc52124/attachment.html>


More information about the mpeg-otspec mailing list