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 <[email protected]> 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
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
