Re: [webkit-dev] Best way to track feature evolution from release-to-release
On Fri, Jan 7, 2011 at 9:30 AM, Ojan Vafai wrote: > On Fri, Jan 7, 2011 at 9:24 AM, Darin Fisher wrote: > >> On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai wrote: >> >>> Right. Having a shared version number across WebKit builds will never >>> catch every case (e.g. patches pulled into branches, disabled features, >>> etc.), but it is better in general than developers using the individual >>> products' version numbers. >>> >> >> Totally agree. We probably just need some kind of dotted notation to >> handle branches. The WebKit trunk should just increment N in "N.0", and >> then branches can increment the minor number. >> > > The branches are not cross-port though, right? We already have individual > product numbers in the UA string that meet this need (e.g. the Chrome or > Safari version number). > > Ojan > That's fair. I think this is a complicated issue due to the likelihood of features being disabled on a branch. So, any "version number" corresponding to the branch point alone may not be sufficient to describe the instance of WebKit. Yeah, the individual product numbers may just have to be the solution there :-/ -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to track feature evolution from release-to-release
On Fri, Jan 7, 2011 at 9:24 AM, Darin Fisher wrote: > On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai wrote: > >> Right. Having a shared version number across WebKit builds will never >> catch every case (e.g. patches pulled into branches, disabled features, >> etc.), but it is better in general than developers using the individual >> products' version numbers. >> > > Totally agree. We probably just need some kind of dotted notation to > handle branches. The WebKit trunk should just increment N in "N.0", and > then branches can increment the minor number. > The branches are not cross-port though, right? We already have individual product numbers in the UA string that meet this need (e.g. the Chrome or Safari version number). Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to track feature evolution from release-to-release
On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai wrote: > On Thu, Jan 6, 2011 at 8:57 PM, Ryosuke Niwa wrote: > >> On Thu, Jan 6, 2011 at 8:31 PM, Darin Fisher wrote: >> >>> Using svn revision numbers has the downside of not reflecting branches >>> very well. A bigger number may correspond to a recent change to an old >>> branch for instance. So, you cannot do simple "if version > N" checks to >>> test for the availability of features. >>> >> >> I think Ojan meant that the version number can be used to learn about >> bugs such as crashes and incompatibilities that have been fixed but cannot >> be detected as a feature. >> > > Right. Having a shared version number across WebKit builds will never catch > every case (e.g. patches pulled into branches, disabled features, etc.), but > it is better in general than developers using the individual products' > version numbers. > > Ojan > Totally agree. We probably just need some kind of dotted notation to handle branches. The WebKit trunk should just increment N in "N.0", and then branches can increment the minor number. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to track feature evolution from release-to-release
On Thu, Jan 6, 2011 at 8:57 PM, Ryosuke Niwa wrote: > On Thu, Jan 6, 2011 at 8:31 PM, Darin Fisher wrote: > >> Using svn revision numbers has the downside of not reflecting branches >> very well. A bigger number may correspond to a recent change to an old >> branch for instance. So, you cannot do simple "if version > N" checks to >> test for the availability of features. >> > > I think Ojan meant that the version number can be used to learn about > bugs such as crashes and incompatibilities that have been fixed but cannot > be detected as a feature. > Right. Having a shared version number across WebKit builds will never catch every case (e.g. patches pulled into branches, disabled features, etc.), but it is better in general than developers using the individual products' version numbers. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to track feature evolution from release-to-release
On Thu, Jan 6, 2011 at 4:39 PM, Ojan Vafai wrote: > On Wed, Jan 5, 2011 at 9:38 AM, Darin Adler wrote: > >> > 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. >> >> I believe that many others use WebKit version numbers based on the ones >> Apple uses. I think this is a good practice, although it might be something >> worth refining. We do want a WebKit version number to mean something >> cross-platform, but it’s not obvious how to accomplish that and meet all the >> other goals of folks using WebKit. >> > > FWIW, Chromium uses the major and minor version numbers listed > in WebCore/Configurations/Version.xcconfig. We'd be happy to use something > not tied to Apple's release process as long as Safari did the same. Giving > web developers one version number to make sense of is important. It would be > extra awesome if they could easily map from an SVN revision to a version > number. Frequently a developer will see that a bug is fixed, but won't know > what the WebKit version number will be. > > Some ideas: > -Use the svn revision number. That has the downside of being tied to SVN > should we want to change version control systems. > -Have a file checked in that corresponds to the WebKit "version" at that > revision. Any port is allowed to increment the number in that file whenever > they please. It's monotonically increasing, not tied to a given version > control system or to an individual port's release process. > > Ojan > > Using svn revision numbers has the downside of not reflecting branches very well. A bigger number may correspond to a recent change to an old branch for instance. So, you cannot do simple "if version > N" checks to test for the availability of features. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to track feature evolution from release-to-release
On Wed, Jan 5, 2011 at 9:38 AM, Darin Adler wrote: > > 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. > > I believe that many others use WebKit version numbers based on the ones > Apple uses. I think this is a good practice, although it might be something > worth refining. We do want a WebKit version number to mean something > cross-platform, but it’s not obvious how to accomplish that and meet all the > other goals of folks using WebKit. > FWIW, Chromium uses the major and minor version numbers listed in WebCore/Configurations/Version.xcconfig. We'd be happy to use something not tied to Apple's release process as long as Safari did the same. Giving web developers one version number to make sense of is important. It would be extra awesome if they could easily map from an SVN revision to a version number. Frequently a developer will see that a bug is fixed, but won't know what the WebKit version number will be. Some ideas: -Use the svn revision number. That has the downside of being tied to SVN should we want to change version control systems. -Have a file checked in that corresponds to the WebKit "version" at that revision. Any port is allowed to increment the number in that file whenever they please. It's monotonically increasing, not tied to a given version control system or to an individual port's release process. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to track feature evolution from release-to-release
On Jan 5, 2011, at 7:06 AM, Tom Bahnck wrote: > 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? That’s almost right. This is roughly correct but omits some important details, such as the fact that it’s not code from the trunk, but rather from a branch off of trunk that Apple makes at some point earlier, and the fact that the tags often are sometimes not created until long after a release. > 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. I believe that many others use WebKit version numbers based on the ones Apple uses. I think this is a good practice, although it might be something worth refining. We do want a WebKit version number to mean something cross-platform, but it’s not obvious how to accomplish that and meet all the other goals of folks using WebKit. Perhaps confusingly, Apple uses the same-format version numbers for both Safari and WebKit that often are the same, but the two numbers are distinct and are not guaranteed to always match. The accurate WebKit version number can be seen in user agent string and in the Mac OS X WebKit framework’s Info.plist file, among other places. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to track feature evolution from release-to-release
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 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 and > , or and not , 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to track feature evolution from release-to-release
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 and > , or and not , 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Best way to track feature evolution from release-to-release
I work on set-top box and PC-based media player stacks which integrate WebKit to render a UI (e.g. guide and storefront) for viewers. 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 and , or and not , etc.? A related question is, what qualifies a given build for a Safari-### tag? 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. Thank you very much for the support you provide. -- Tom Bahnck Motorola Mobility, Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
