(... and what should we do regarding Nightly-only features?) TL;DR: I think we should send announcement emails to dev.platform for landed features, and we should continue enabling unstable features in Nightly by default, but warn about them in the announcement, and be less aggressive with letting features ride the trains.
Esteemed All, in the wake of the the recent excitement around Array.prototype.contains[1][2], I think we should find a better way to announce landing of features and, importantly, their status. For DOM APIs, there's a clear process for all this, described in the WebAPI Exposure Guidelines[3]. I don't think a wholesale adoption of these guidelines makes sense for SpiderMonkey: the vast majority of what we implement in terms of new/changed functionality is following the EcmaScript specification, or at least a draft of the next version. Since that spec is developed in a consensus-based manner, we don't usually experience many issues regarding what can be made available to content, or how that may happen. I say "vast majority" because there are some features we work on that deviate from this. Namely, the Typed Objects work is based on a very early draft and the API will change before stabilization, and the SharedArrayBuffer work is in a much earlier stage of the standardization process, still. Then, there are features or changes that are part of the specification draft, but were we have doubts about their web compatibility. One example is the change in behavior of new instance-returning Array methods: per ES6, those are supposed to use the `this` object's .constructor function instead of the original Array constructor to create the return value. And finally, tc39 has agreed on a new process for versions after ES6[4], part of which is that proposed spec additions go through a set of stages before being accepted for integration into the spec. One of these steps is implementation in two engines. (See [5] for a list of current proposals). For this process to work, timely implementation is crucial, so I think we can except to have to work with less stable specifications going forward. Oh, and it's not like we haven't been burned by supposedly stable features changing after we implemented them and made them available to content (and chrome/addons code). I think we should largely continue what we're currently doing on the implementation side. Probably, we should be slightly less aggressive with letting features ride the trains, though. We can and should, however, do better on the announcement front: for features that might not be ready for more than experimentation, an announcement helps prevent people from using them (as happened with [].contains). For stable features, OTOH, it might actually be kinda nice to let people know about them. Yes, we do release notes, but my impression is that for in-tree usage, announcements on dev.platform will be far more effective. That is all. thanks, till [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1075059 [2] https://groups.google.com/forum/#!topic/mozilla.dev.platform/z0WD8viuINQ [3] https://wiki.mozilla.org/WebAPI/ExposureGuidelines [4] https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU/edit [5] https://github.com/tc39/ecma262 _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
