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

[Tom Bahnck]

Thank you.  If my understanding is correct wrt to Apple's release process,
when given the chance, Apple tags the WebKit trunk under the name
"Safari-###" in the /tags directory.  This contains all source from the
WebKit trunk, including tools/bugzilla/test/etc. code.  When making a Safari
release, Apple publishes WebKit code selected for production to a "Safari
#.#" directory in /releases/Apple, which correlates to a Safari-### tag by
changeset notes (e.g. "Tag for WebKit in Safari 5.0.3 (WebKit 533.19.4)") --
in the preceding example, "WebKit 533.19.4" correlates to
/tags/Safari-533.19.4 as base.  Is this correct?

The user agent string in Chromium cites, for example, "AppleWebKit/534.10".
Does this refer directly to the /tags/Safari-534.10 code base?  In other
words, this is just an example of an organization chosing to use a tag
created by another organization?  Some refer to the Safari-(5##) number as a
WebKit release, so it is important to clearly understand the distinction.

Thanks,
Tom


On Tue, Jan 4, 2011 at 5:49 PM, Darin Adler <darin at apple.com> wrote:

> 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
>
>


-- 
Tom Bahnck
Motorola Mobility, Inc.
215-323-1830
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110105/57e4c16a/attachment.html>