Stage five #16
Stage five #16
Conversation
This patch defines requirements for reaching Stage 4 as being satisfied by a sufficiently used native implementation, such as a JavaScript engine in a web browser in a "preview" mode. This patch does not encode the committee's current policy but rather defines a new policy.
Stage 5 is what happens when two implementations ship, on top of Stage 4, which comes with two complete native implementations.
|
@littledan I do not support this proposal. The answer to your question on whether a new stage 5 as you propose would give me confidence is no. I appears that I haven't made my position clear. Here are the reasons why I don't support shipping stage 3 features in stable, released Safari.
I understand the position that @domenic is making. However I find it difficult for JavaScriptCore to fill the role as a stage 3 -> 4 stable implementation, given the reasons stated. This in no way changes my desire to aggressively implement ES features in JSC and provide implementor feedback as appropriate. |
|
@msaboff I'm still having trouble understanding your position. Maybe we have an even more basic question. Would Safari have the confidence to ship features to stable, if the features moved to an amended nu-stage 4 (as embodied by the pull request in #15), but Safari was the first browser to ship them? |
|
@domenic I assume that by nu-stage 4 you are referring to the following:
With a nu-stage 4 as described there, I wouldn't want to ship features at that stage in a stable shipping Safari. My position is basically applying a literal interpretation of the current process document. Features at stage 3, aka Candidate stage, are expected in Spec compliant implementations. Features at stage 4, aka Finished stage, are expected in Shipping implementations. I see Safari Tech Preview as a Spec Compliant implementation where spec issues, if any, are worked out. Released Safari versions are Shipping versions. I don't want Candidate features in a Shipping Safari. |
|
Great, thanks, that clarifies things. In that case I don't see a need for #15 (which changes stage 4 to nu-stage 4), as it doesn't help anyone ship any sooner. |
|
@msaboff Here’s my attempt at distilling your views (based on #15 (comment) and your last comment):
…where any mention of Stage 3 or Stage 4 refers to the stage as defined in the current process document. Is that an accurate representation of your stance? If not, where did I go wrong? |
@mathiasbynens, that is a good summary of my views. I understand that my interpretation of the implementation requirements for stage 4 advancement are different than what reportedly the committee agreed to in discussions prior to my TC39 involvement. |
|
@msaboff, then I am confused. If we change stage 4 to nu-stage 4 so that your interpretation matches the process document, you've said you would no longer be comfortable shipping features in Safari during stage 4, per #16 (comment). |
|
I believe that @mathiasbynens was referring to the current stages 3 and 4. @domenic, I may be confused with fully what nu-stage 4 is. My understanding of your proposed nu-stage 4 change to the process document is that it would add an intermediate stage between the current stages 3 and 4. A feature would still need to reach nu-stage 5 (current stage 4) in order to be added to the standard. In that model, as I said in #16 (comment) I wouldn't want to ship features at that stage in a stable shipping Safari. I would fully support shipping nu-stage 4 features in a preview Safari. Whatever stage has the name Finished and Implementation Types Expected as Shipping or the equivalent thereof, that is the stage for features that I'd ship in a stable release of Safari. That is the current stage 4 and I think that maps to nu-stage 5. |
|
@domenic I think the crux of the issue is that once something reaches stage 4 in its current form it's "locked-in" for the next standard. Since getting it taken out of the main TC-39 repo requires consensus, AFAIK. My concern is exemplified by the following example: Browser A ships feature, per the requirement to get to stage 4. After this feature has shipped another browser (or even individual), B, blocks the proposal from reaching stage 4 for whatever reason without backwards incompatible changes. Now browser A either pays the cost of backwards incompatible changes or a having (a likely unused) non-spec compliant feature in their codebase forever. Under the new system browser B must either implement the feature or admit they no longer intend to implement the standard. |
Sorry, I miscommunicated then. What I mean by nu-stage 4 is that stage 4 would be modified to lower the bar so that it becomes a place where unstable features, shipped in unstable browser releases, are allowed into the spec. Thus, things would change during the modified stage 4 (where only preview releases are necessary) as often and as much as they do during the current stage 3. In your comment, you said you would not be comfortable shipping in a version of stage 4 where the bar was lowered in that way. Is that incorrect? If we lowered the bar to stage 4, so that things get merged into the spec despite being unstable/not shipped in 2 stable browsers, would you be able to start shipping things to stable Safari earlier?
I don't think what repo it's in is very interesting. Blocking the feature entirely, as in your example, would have to happen at stage 2. Stages and being in the standard don't really have much impact on interoperability. Even if we lower the bar for stage 4, so that things can go in the spec despite not being shipped to stable users, a browser could still decide based on the data they gather during their unstable stage 4 release that the feature is not suitable for shipping in stable to that broader user population. Multiple browsers could decide this, in fact. All four browsers could decide this! There'd no longer be a process stopping that from happening. Interop will still not be obtained, and we'll end up in a situation similar to tail calls. That is, something is in the spec, but got there without multiple implementers being willing to ship it to their stable populations. So while browser A can say they implement the standard via a technicality of the process, they cannot say that they implement the actual cross-browser interoperable JavaScript language. Instead they implement a variant that has the committee's blessing by virtue of the fact that browser A can now veto any attempts to align the spec with web reality. I don't think we should be optimizing for such technical conformance in our process, but instead putting things into the spec that are actually proven to be interoperable and shippable to stable populations. |
|
@domenic, I don't think this discussion is going anywhere. I have stated preiously at several points in this exchange the stage level of features that I would include in a preview version compared to a released version of a browser. (See #16 comment, #16 comment and #16 comment. I appreciate @mathiasbynens summary. Although I would support a change in the interpretation of stage 4 entrance criteria with respect to the meaning of shipping implementations, I am not arguing for that change. My responses here are intended to inform others on the committee of the feature release actions I would take as one implementor. |
Does the concern have to do with the polarity of blocking in our consensus model, (that anyone could block something from moving ahead, as opposed to the default being automatically proceeding into the spec)? Maybe we could somehow write in the right guarantees to prevent this sort of scenario and give more confidence to Stage 4 proposals. |
|
@msaboff, I'm sorry you feel this discussion is not going anywhere. I'm still confused as to Apple's position, so I'd appreciate your patience. For me at least, the discussion is going places, if you can help un-confuse me. This is important for shaping my position on the proposed changes @littledan is pushing. To be concrete, we're trying to establish the effect of @littledan's proposals on whether they would help Safari ship features to their stable channel sooner. In effect, the current combination of the process document as-written, and Safari's policy of waiting for stage 4 as-written, requires waiting for two other browsers to ship to stable first. Considering #15, reviewing the comments you linked, my conclusion is that if we accept #15, Safari would no longer ship features in this newly-modified stage 4, and would wait until some unspecified later time (which is no longer covered by the process document) when the feature becomes stable. Thus, this would not help Safari ship features to stable sooner. I base this on the following:
However, this is potentially contradicted by the following:
So as you can see, I'm still confused between the things you've said and the ways @mathiasbynens has characterized your views. So if you would be willing to help me out, the concrete question is: if we accepted #15, and thereby changed stage 4 to a less stable stage (similar to the current stage 3), would Safari still be interested in shipping to stable during stage 4? |
I believe part of the confusion here is that we are talking about #15 and #16 in this one thread. Which proposed change of @littledan's are you talking about, #15, #16 or both? I'm not for this proposal, #16, as I think it complicates the process for little gain. The real issue is in #15, i.e. what does Significant in-the-field experience with shipping implementations, such as that provided by two independent VMs mean? I believe that preview or behind-a-flag implementations meets that standard, provided those implementations are tried by developers and users. [Quote out of order]
I misunderstood your reference to nu-stage 4 being to #15 when replying in #16 comment. This PR (#16) talks about an additional stage 5 that I took as nu-stage 5. My prior comments about nu-stage 4 are made with the assumption that nu-stage 5 is the Finished stage. Let me clarify that my response to #15 is that I would support shipping a stage 4 feature in a stable shipping Safari.
#15 proposal would allow Safari to ship sooner, modulo the Safari release frequency.
My confusion above explains why you believe that. If a feature is at the Finished stage 4, I would want to ship that feature in the next Safari feature release.
I disagree with that assessment. I don't think a stable browser locks in a feature. That is the job of TC39 moving the feature to stage 4. The ES standard defines the feature and not a stable shipping browser. As others discussed in #15, two implementations should be sufficient signal to the committee to lock down a stage 3 proposal and make it stage 4.
I don't interpret stage 4 differently, I interpret one of the entrance criteria for stage 4 differently. That is what #15 is all about. I disagree with your assertion that stage 4 after the criteria modification in #15 would no longer be stable.
First I disagree with the premise of your question, that changing one of the stage 4 entrance criteria destabilizes stage 4. Under #15, stage 4 is the final stage when we declare a feature as finished and to be included in the next version of the ES standard. Premise disagreement aside, I would support shipping a stage 4 feature in a stable shipping Safari, even before it appears in the next ES standard. Stability of a feature should not be defined by what browsers implement it, but that it has gone through various and thorough reviews by champions, the committee, implementors, acceptance test, developers and users. Putting a feature in two stable shipping browsers only assures that implementors have reviewed it. Other stages provide review opportunities for some of the other stakeholders. It is incumbent upon champions, implementors and TC39 as whole to assure that developers and users try out the 2 or more implementations of a stage 3 proposal and provide relevant review feedback. If our sole criteria for stage 3 implementations before moving to stage 4 is that they exist in stable shipping browser, we have no idea how many developers use the feature let alone their feedback. To reduce any further confusion, I think this PR should be closed and further discussion on this topic be moved to #15. |
|
Closing in favor of the current process document, with its deliberate ambiguity and lack of a requirement for two shipping implementations or qualification of which kinds of implementations count. |
Proposed alternative to #15
The idea here is to make Stage 4 what @msaboff considers important for finality, Stage 5 what @domenic considers important. The changes between Stage 4 and 5 are even more limited in scope, and should be based on what's discovered by shipping itself, e.g., web compatibility issues. The big open question would be, would the requirements for Stage 4 give enough finality to give an implementer like @msaboff confidence to ship outside of a "preview" version?