Re: Draft WebPlatform.org Blog Post on HTML5 CR

Unless I am completely misinformed here... what you are describing seems
more like a beta release than a release candidate. I believe a beta release
generally has all of the features that are supposed to be implemented
(sometimes some polish is needed) in a said version and some of them may
get dropped. Release candidates, on the other hand, should be feature
complete and features are generally not dropped from them.
Proposed recommendation (which you have not mentioned) is, in my opinion,
probably the equivalent of a release candidate.


☆*PhistucK*



On Tue, Dec 18, 2012 at 1:20 AM, Doug Schepers <schepers@w3.org> wrote:

> Hi, folks-
>
> As you may know, HTML5 was published today as a Candidate Recommendation
> at W3C.
>
> W3C's MarComm team has already done a good job with the official W3C
> communications about HTML5's CR release [1]; it covers it well, explains
> everything it needs to explain, answers open questions, and feeds the story
> to the press in a easily digestible way. As part of W3C DevRel, I'd like to
> make standards be more relevant and relatable to the average web developer
> or designer.
>
>
> It seems advantageous for WebPlatform.org to also talk more about progress
> on the Open Web Platform, including notable implementations, browser
> releases, and standardization progress.
>
> I decided to take a rather different approach than W3C's formal
> communications, to explain HTML5 CR to developers in a way that isn't
> already covered. I framed it in terms of something they can relate to
> better: browser release cycles (and software releases in general). I hope
> this is a good complement to what W3C's MarComm has done.
>
> So, as I mentioned last week, I plan to do 2 things: write a blog post [2]
> (or appended below for those that don't have access to the blog), and make
> an HTML5 page [3] on Web Platform Docs.
>
> By laying out this blog post the way I've done it, it gives us the chance
> to build on that metaphor (spec as software) in future posts.
>
> I believe that adding more kindling to the bonfire we're already blazing
> today will add little extra light and heat, so I plan to wait a couple
> days, maybe until Wednesday, to post this blog entry, to throw another log
> on the fire as it's dwindling.
>
> Chris and I are still working on the HTML5 page [3] for Web Platform Docs,
> but it will be ready in time for this blog post.
>
> So, if you have suggestions about this blog post, or about what we can do
> for HTML5 on WPD, please let me know.
>
>
> I've already gotten some feedback that CR is more like an RC (release
> candidate) than RTM (release to market). I'd like to hear from different
> browser vendors on their terminology and process, so I get it right...
>
>
> [1] http://www.w3.org/2012/12/**html5-cr<http://www.w3.org/2012/12/html5-cr>
> [2] http://blog.webplatform.org/?**p=67<http://blog.webplatform.org/?p=67>(admins only)
> [3] http://docs.webplatform.org/**wiki/html/html5<http://docs.webplatform.org/wiki/html/html5>
>
> Thanks-
> -Doug
>
> [[
> HTML5 is Going Gold
>
> On Monday, W3C published the HTML5 specification as a “Candidate
> Recommendation” (CR). What does that mean to Web developers and designers?
> How does that affect your daily job? And how does this relate to Web
> Platform Docs?
>
> Standardization is not something most Web developers and designers deal
> with directly, and many of you may not be clear on some of the details. But
> you are all familiar with software release cycles, so I’ll draw the analogy
> with browser releases (and really, it’s a pretty close match).
>
>
> Going Gold
>
> In browser release terms, for example, CR is the equivalent of a release
> candidate branch with feature freeze. That means that there’s still plenty
> of work to do before the final release, but we’ve defined the set of
> features that’s in, and what’s out. It’s fair to say HTML5 is going gold
> (that is, CR is similar to RTM).
>
> General Availability
>
> The final major milestone is publication as “Recommendation” (Rec) status…
> if this were software, this would be the formal launch or public release,
> also known as General Availability (GA).
>
> What work has left to be done between CR and Rec? Mostly testing. We need
> tests (lots and lots of tests) to make sure that all the features are
> defined clearly enough to be implemented consistently across “User Agents”
> (i.e., all the desktop and mobile browsers, authoring tools, bots, and
> anything that reads or writes HTML on behalf of the user). We also test to
> make sure that it is not only implementable, but actually implemented… in
> other words, before we say that the spec is ready to be considered a
> standard, there need to be at least two browsers (or more, preferably) that
> support each browser feature. Once we create all the tests that are needed,
> usually many tests for each feature and combination of features, we gather
> them into a test suite, and test all the various User Agents and record the
> results in an Implementation Report. This Implementation Report is the
> primary piece of evidence used to judge whether a spec is ready to be
> declared a standard… that is, ready to ship.
>
> Like with a browser release candidate, there may be features that are
> pushed to the next release. In other words, they are dropped from the
> branch, but not the trunk.
>
> Back on the Trunk
>
> But just like with a browser release, the work is never done… there will
> always be bug reports and fixes, and sometimes even changes. W3C
> Recommendations are revised, through new editions, or even new versions.
>
> Because development doesn’t stop with a “final” release. The Working Group
> keeps working on the master branch (or “trunk”): the main spec, with new
> features, some experimental, some solid and well-defined.
>
> In this case, the next branch is the HTML 5.1 spec, which was also
> published Monday. Right now, it’s a “point-release” spec, because it
> doesn’t have enough new features to warrant a new major release… but as it
> develops over time, it might morph into HTML 6.
>
> Nightlies
>
> The equivalent of the nightly browser build is the Editor’s Draft (in
> fact, the HTML5 editors even call their Editor’s Draft’s “nightlies”).
> That’s where you go to find the next generation of possible features, to
> try out the ideas, and to comment. Some of the features will need only a
> little revision and polish, and some will be dropped completely, because
> they didn’t do what they were designed for, or because they introduced
> security holes, or any other reason that experimental work doesn’t make it.
>
> Extensions
>
> The HTML WG, like the CSS and SVG WGs, is also experimenting with modular
> specs. You can think of these as browser extensions… developed on the side,
> smaller and more focused, easy to iterate and refine. And some of these
> features might be folded into the trunk. Some of the modules also published
> on Monday include Canvas 2D (aka, Canvas) and the new spec for the HTML
> <main> element. These are each on their own release cycles.
>
> So, in a nutshell, that’s a portrait of a specification as a browser
> release.
>
> Web Platform Docs
>
> So, how does this relate to WPD, and the Web Platform project in general?
>
> Specific to HTML5, we’ve created a dedicated HTML5 page on WPD that breaks
> down the features of HTML5  into categories like new elements, attributes,
> and APIs, existing stuff, and things that are now obsolete. We also have
> tutorials that can help you get started.
>
> But more generally, we recognize that all that status information is hard
> to keep track of, so we are doing our part to keep you informed.
>
> On this blog, we will let you know about those milestones that we think
> you should be aware of, including opportunities to review specifications
> early, while there’s still a chance to change them. We’ll also do a roundup
> of progress in various specifications.
>
> We’ll also be working with the organizers of Test the Web Forward, and we
> hope you will too. The best way for you to ensure the features you want get
> developed quickly and interoperably is to do something you already do:
> write and review tests. (And you should also review the specs, if you’re so
> inclined.)
>
> Going forward, as WPD matures, we will reflect all this detailed
> information about browser support more systematically. We are working with
> PPK from QuirksMode.org and Alexis Deveria from CanIUse.com on plans to
> integrate their data . In addition to that, we will be integrating results
> from W3C’s own test suites and implementation reports, letting you drill
> right into the tests. We won’t leave you guessing about how we decide when
> and where and if something is supported… we’ll back it up with solid facts,
> because we know you need to make decisions as a professional.
>
> This week, the Web just got a little better, a little more stable, and a
> little more powerful.
> ]]
>
>
>
>