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

[Darin Fisher]

On Thu, Jan 6, 2011 at 4:39 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Wed, Jan 5, 2011 at 9:38 AM, Darin Adler <darin at apple.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110106/4c4a13fb/attachment.html>