Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stage five #16

Closed
wants to merge 2 commits into from

Conversation

@littledan
Copy link
Member

commented Nov 7, 2017

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?

littledan added 2 commits Nov 1, 2017
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.
@msaboff

This comment has been minimized.

Copy link

commented Nov 7, 2017

@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.

  • We don't want to expose users to possibly premature features that might change as they make it to stage 4. I want to avoid having a period of time where released Safari has a non-standard feature and then having to correct it soon thereafter.
  • I view Safari Technology Preview as the JavaScriptCore team's stage 3 -> 4 release vehicle. We implement and make available in STP features that are mostly baked at the TC-39 process, likely stage 3, but not exclusively. This provides us some exposure with feature champions, early adopters and compatibility tests. If/when issues come up with our implementation and/or the feature, we address them.
  • The historic Safari official release schedule has been once a year up until 2017. This year, we shipped 2 stable "feature" releases. I cannot comment on future plans, but such infrequent stable releases are not that helpful if required for feature advancement to stage 4 given TC-39 yearly cycle. Edge appears to have a similar, less frequent release history. The "stable" release schedules of Chrome, at 8 times a year, and FireFox, at 7 times a year, are much more likely to provide the widely adopted feedback that @domenic and others are looking for before advancing a feature to stage 4 in a timely manner.

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.

@littledan

This comment has been minimized.

Copy link
Member Author

commented Nov 7, 2017

Thanks for baring with me through these versions and all the feedback @msaboff . If this doesn't work for you, maybe we could reconsider #15 .

@domenic

This comment has been minimized.

Copy link
Member

commented Nov 8, 2017

@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?

@msaboff

This comment has been minimized.

Copy link

commented Nov 8, 2017

@domenic I assume that by nu-stage 4 you are referring to the following:

If we lowered the requirements to stage 4 to be only preview/beta releases, then I think things would change just as much during nu-stage 4 as they do during current-stage 4. Which would mean that Safari would then choose not to ship nu-stage 4 features, if I understand them correctly. So we're right back where we started.

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.

@domenic

This comment has been minimized.

Copy link
Member

commented Nov 8, 2017

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.

@mathiasbynens

This comment has been minimized.

Copy link
Member

commented Nov 8, 2017

@msaboff Here’s my attempt at distilling your views (based on #15 (comment) and your last comment):

  • You’re comfortable shipping Stage 3 features in preview releases.
  • You’re comfortable shipping Stage 4 features in stable releases (only).
  • In your interpretation of the current process document, the minimum requirement to reach Stage 4 is to have two native implementations in preview releases.

…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?

@msaboff

This comment has been minimized.

Copy link

commented Nov 8, 2017

@msaboff Here’s my attempt at distilling your views (based on #15 (comment) and your last comment):

...

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.

@domenic

This comment has been minimized.

Copy link
Member

commented Nov 8, 2017

@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).

@msaboff

This comment has been minimized.

Copy link

commented Nov 8, 2017

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.

@kmiller68

This comment has been minimized.

Copy link

commented Nov 8, 2017

@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.

@domenic

This comment has been minimized.

Copy link
Member

commented Nov 8, 2017

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

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 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.

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.

@msaboff

This comment has been minimized.

Copy link

commented Nov 8, 2017

@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.

@littledan

This comment has been minimized.

Copy link
Member Author

commented Nov 8, 2017

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.

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.

@domenic

This comment has been minimized.

Copy link
Member

commented Nov 9, 2017

@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:

  • #16 (comment) says you would not support exposing users to premature features that might change, but under #15, stage 4 features might change (since they have not been sufficiently locked down by being shipped to stable browser populations).
  • #16 (comment) says you would not support shipping features in stable Safari during the nu-stage 4, i.e. the stage 4 as modified by #15.
  • #16 (comment) states that if we accepted #15, you'd need to wait until stage 5 (which #15 declines to specify) before shipping in Safari.

However, this is potentially contradicted by the following:

  • #16 (comment) indicates that you're comfortable shipping features in stage 4, but you interpret stage 4 differently from the current written definition, instead preferring the definition as modified by #15. This indicates that if we accepted stage #15, even though stage 4 would no longer be a stable stage, you'd still ship during it, perhaps because you've never thought of stage 4 as a stable stage?

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?

@msaboff

This comment has been minimized.

Copy link

commented Nov 9, 2017

@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.

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]

  • #16 (comment) says you would not support shipping features in stable Safari during the nu-stage 4, i.e. the stage 4 as modified by #15.

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.

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.

#15 proposal would allow Safari to ship sooner, modulo the Safari release frequency.

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.

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 base this on the following:

  • #16 (comment) says you would not support exposing users to premature features that might change, but under #15, stage 4 features might change (since they have not been sufficiently locked down by being shipped to stable browser populations).

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.

However, this is potentially contradicted by the following:

  • #16 (comment) indicates that you're comfortable shipping features in stage 4, but you interpret stage 4 differently from the current written definition, instead preferring the definition as modified by #15. This indicates that if we accepted stage #15, even though stage 4 would no longer be a stable stage, you'd still ship during it, perhaps because you've never thought of stage 4 as a stable stage?

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.

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?

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.

@littledan

This comment has been minimized.

Copy link
Member Author

commented Nov 28, 2017

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.

@littledan littledan closed this Nov 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.