<div class="gmail_quote">On Fri, Aug 14, 2009 at 12:35 PM, Joćo Eiras <span dir="ltr"><<a href="mailto:joaoe@opera.com">joaoe@opera.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred.</div></blockquote><div><br></div><div>As a browser implementer, I have certainly not found the dynamic nature of the spec to be a problem. In fact the opposite is true: problems in the spec can be fixed quickly when they're raised.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"></div>Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal.</blockquote>
<div><br></div><div>As opposed to if we froze versions, which would mean implementers would implement part of the old specification, and meanwhile the new spec has changed it.</div><div><br></div><div>In other words, I don't see how versioning reduces this problem at all in practice.</div>
<div><br></div><div>Furthermore, you seem to be proposing versioning well in advance of CR status, since you say it will take time to reach CR. What is the metric by which we'd decide to "freeze" a spec, then?</div>
<div><br></div><div>PK</div></div>