CFC: Transition V1 spec to CR

[jakearchibald]

This is Call For Consensus (CFC) to transition the current V1 spec to Candidate Recommendation.

Until now we have keeping two specs up to date, where new features go into the main spec, and fixes go into both specs. As the two diverge, it's becoming harder to keep the two in (a)sync, so I'm looking forward to moving V1 to CR, then keeping the main spec as a living spec.

If you agree with this, feel free to 👍 this comment and brighten my day. If you don't agree, SPEAK NOW OR FOREVER HOLD YOUR PEACE.

If no one puts the brakes on before 22nd August 2019, we'll start the process to move V1 to CR.

cc @ylafon @jatindersmann @aliams @jungkees @youennf @hober @asutherland.

[asakusuma]

Not opposed, but I did want to raise a concern that #614 (#1440, #1443) may require core changes to the spec, as well as coordination with other specs, like background fetch, push notification, and clear-site-data.

Skimming the definitions of the spec track levels, this section makes me question whether CR is appropriate, given the outstanding issues above:

Substantive changes that require coordination with other groups will cause the document to return to Working Draft status.

https://www.w3.org/Consortium/Process/Process-19991111/tr.html#RecsCR

[youennf]

That sorts of make sense to me given the current state of adoption.
I wonder though what the benefits/goals of moving the v1 spec forward are if implementers and web developers will actually focus on the living standard.
Is it more of a process kind of thing? Will it help identifying interop bugs/test coverage limitations?
Would it make sense (or is it possible) to just jump in the living spec world?

[jakearchibald]

@asakusuma

Service worker registrations are already killed today, it's just hand-waved in the spec. I agree it may be a substantial PR to the spec, but my interpretation of a "change" here was a backwards incompatible change, eg where a return type changed. In terms of killing service worker registrations, we currently have some undefined behaviour which will become defined in the living spec.

@ylafon does this interpretation match the new "living spec" world? How 'complete' do we need to be?

[jakearchibald]

@youennf

I wonder though what the benefits/goals of moving the v1 spec forward are if implementers and web developers will actually focus on the living standard. Is it more of a process kind of thing?

Having two living specs has been a source of confusion for developers, which is why we ended up putting a big warning on https://w3c.github.io/ServiceWorker/v1/. Also, having to update both specs has made the editors reluctant to make substantial changes (eg, moving the cache API into its own spec).

Going to CR is part of W3C's legal process, but I understand that once we've done that for V1, we can continue with a living standard, and get the same legal protection through automated snapshots, which don't involve the kind of formality we're having to go through here.

[ylafon]

@jakearchibald no spec will ever be complete until it is dead, so any "cast-in-stone" document will represent no more than part of what is currently implemented and considered as stable. But of course, once stable things may be updated in the future, or even removed (provided there are evidence they were not used), but yes, documenting as much as possible in the v1 what is subject to change is a good thing, we already know we want to move to a "living spec" model once v1 is done, but not for v1, for the main doc. Having a first stable document (ie: a REC) is the first milestone of this.

[youennf]

Having two living specs has been a source of confusion for developers

Agreed. My fear is that going forward with v1 as a REC might further increase confusion, especially since v1, by the time it becomes a REC, might be quite different from the living standard that browsers will implement.

Going to CR is part of W3C's legal process, but I understand that once we've done that for V1, we can continue with a living standard,

Is it going to CR or REC which is a prerequisite?

Going from CR to PR and then REC will probably take some substantial time and energy, at least to the chairs and editors. For instance, there will be a need to show full interoperability of the spec. There will be a need to prove that all issues related to v1 have been properly dealt with.

we already know we want to move to a "living spec" model once v1 is done, but not for v1

I am not clear whether the group does not want to do that or cannot do that.
@ylafon, can you clarify this?

[jakearchibald]

My goal here is to get V1 out of the way. I don't mind if that's by pushing it to CR & REC, or by dropping it and going straight to a living spec.

I would still want the CR/REC to carry the warning that V1 currently carries, as it isn't the spec we'd want developers looking at.

@ylafon @aliams can you make the case for moving V1 to REC rather than going straight to a living standard?

[ylafon]

The living document process that was in discussion in the AB still required a fixed document first, so yes, we need a REC of V1 before forgetting it and keep v2 as the living spec, while waiting for the AB to figure out the details of the living spec process.

[jakearchibald]

@youennf given the above terms, are you happy for us to proceed pushing v1 to REC?

[youennf]

Sure, the sooner we go to living spec, the better.