- From: Nathan <nathan@webr3.org>
- Date: Tue, 15 Feb 2011 20:30:08 +0000
- To: Ian Hickson <ian@hixie.ch>
- CC: www-archive <www-archive@w3.org>
Ian Hickson wrote: > On Tue, 15 Feb 2011, Nathan wrote: >> The W3C timeline and model of releasing major versions "5" "6" is far >> too slow, whilst the WHAT WG Living Standard is a constantly moving >> target that the common web folk simply can't keep up with. >> >> It would be great to see the two approaches balanced such that >> announcements are made like "HTML has just been updated, features a,b >> have been added, bugs h,j,k have been fixed and z has been deprecated". > > Why do people want a specification of HTML with known bugs but without > those bugs being fixed as soon as possible? Wouldn't referring to a > specification with known bugs be harmful to interoperability? Indeed, perhaps I haven't been clear, I'm suggesting that if bugs h,j,k have been fixed and are ready to push to the rec, then agree they are fixed and push them, not to wait 18 months until features a,b are also ready to be pushed. Essentially it's just a matter of getting the right balance, bug fixes and minor issues could be rolled out every time they're agreed as fixed by the WG, likewise with major features - everytime it's agreed that something is "done" and ready for the rec, then it should be pushed to the rec. This is different to having an editors draft which is constantly in development (with new features and fixes just pushed whenever), and different to having an out of date legacy spec because the group is waiting for "everything" to be done before pushing to rec. Make sense?
Received on Tuesday, 15 February 2011 20:32:36 UTC