[webkit-dev] Best way to track feature evolution from release-to-release

[Darin Adler]

On Jan 4, 2011, at 1:47 PM, Tom Bahnck wrote:

> We are looking for the best way to identify the supported syntactical elements in each release, such as HTML/CSS tags/properties/values. Eric Seidel's excellent lecture on the Google code channel points out that the /WebCore/dom/*.idl /WebCore/html/*.in files list standard page-level tokens, which are used to build a string cache.  This is a very useful start; however, is there a way to correlate the supported attributes to elements?  E.g., considering "src", to know that "src" is supported for <img> and <video>, or <img> and not <video>, etc.?

I can’t think of a simple way to find the complete list of what attributes are supported for each element. Much of the code would be in the elements’ parseMappedAttribute functions, but not all.

A project to create a table that tracks this could give us a head start. I’m sure we can keep such a thing up to date if it’s checked in alongside the sources to the classes themselves.

> A related question is, what qualifies a given build for a Safari-### tag?

Those tags just reflect what WebKit Apple chose to ship with versions of Safari. The Safari tags are our way of precisely stating after the fact to the rest of the WebKit community exactly what we chose to ship with a given version of Safari.

But what goes into each is Apple-internal decision. Apple, like others who put out WebKit releases, does our own branching and release management and makes up our own mind about what does and does not go into each release.

We don’t have a shared release process for the team overall.

> Understanding how frequently tags are made public would inform us (roughly) of how many release candidates we need to evaluate, when for example, upgrading our embedded WebKit release from X to Y, in search of support for a new feature.

We put out tags for releases whenever we have the chance. It’s not a part of a release process; just something we do later on to make things clearer for the record.

As I said, the Safari tags are an Apple thing, not really something intended for use by all the others working on the WebKit project. That’s why it’s in the releases/Apple directory in the Subversion repository. I encourage others producing WebKit releases to make similar tags, as the WebKitGTK folks have done.

    -- Darin