Edge is recognized as Edge 12 about testswarm

[Krinkle]

I'm not sure I see the problem. This screenshot is of the run page. The run page shows the full browser and os name and version as recognised by ua-parser. It is not used for anything other than showing you what the current browser is (and in the test results).

It is not used for fragmenting job page columns and does not affect distribution of test runs to clients. For that, only the specified userAgent descriptor is used, which in your case is unified for all of "Edge".

For example, matching { browserFamily: Chrome, browserMajor: 46 } will result in a column "Chrome 45" but the results will document e.g. "Chrome 46.0.2455.0 / Mac OS X 10.10.4". It's a one-to-many relationship.

If the issue is that the label itself uses "12.0" as a version and doesn't show the build number, that's up to upstream ua-parser, but doesn't affect us in any way.

TestSwarm does actually display the minor and patch versions if they are available. And ua-parser supports that as well for Edge. E.g. user agent Edge/12.9600 shows "Edge 12.9600 / Windows 10". It isn't generalised as 12.0 in TestSwarm nor ua-parser.

[mgol]

You're right, I thought the data displayed is the one identified by TestSwarm mappings, not by ua-parser. I've just started a jQuery Core Periodic run and Edge displays without a number as expected: http://swarm.jquery.org/job/937.

I'll close this issue then.

[jdalton]

Based on the MS Edge blog guidance for dev-facing features you should track against the EdgeHTML version rather than the Edge app version.

[mgol]

@jdalton This won't work since if we specify a major it has to match what BrowserStack provides. And BrowserStack uses the app version, i.e. 20 currently. Sauce Labs does sth similar btw (but it also specifies the build version as minor which BrowserStack doesn't do).

This is going to get incredibly confusing once the EdgeHTML version reaches 20; I think it will cause problems that the numbers won't match. People will constantly wonder what "Edge 22" really means in a particular comment, display value etc.

[mgol]

BTW, we're currently thinking how to mark Edge workarounds in the code comments in jQuery: jquery/contribute.jquery.org#95 (comment). Do you think to reduce confusion we should write EdgeHTML 12-13+, i.e. EdgeHTML and not Edge to make it clear we're talking about the engine number? In every other case we write the name of the browser and not its engine so it would get inconsistent but otherwise it'd get even more confusing...

[jdalton]

I've reached out to sauce labs to adjust their version from 20 to 12. Sauce is open to changing they just wanted an official doc or blog post to reference (which is out now) so those wheels are in motion.

I'll do I've done similar outreach for BrowserStack and HTML5test.

[mgol]

Oh, if they changed that that would be great! :)

[jdalton]

My advice would be to call it MS Edge 12-13. I'm hoping now that the blog post is out we can correct the current use so that the whole 20 vs 12 thing will be just a minor confusing note of the past. I and others will continue to push for a more straight forward version representation in the about dialog too.

[gibson042]

Based on that blog, EdgeHTML seems like the clearest identifier for our Support comments. I actually prefer engine version to browser version, but we don't always dig deep enough to discover the former. And we can always reference the browser itself if we need to (but fingers crossed that we won't).

[jdalton]

Tools and sites are that reference platform features (like ES6 compat table, caniuse, HTML5test) are being advised to reference Edge or MS Edge then 12 or 13. Treat it like any other browser. Getting bogged down with the platform dll name should be avoided.

[mgol]

I actually prefer engine version to browser version, but we don't always dig deep enough to discover the former.

The engine version isn't always accurate as e.g. various mobile browsers are WebKit- or Blink-based but they often add their own quirks to the engine; one example is Yandex.Browser. Therefore, I think we should mention browsers and not engines as that's as much unambiguous as we can be.

If we add @jdalton's recommendation that all tools should use Edge and the engine version then it doesn't seem worth it to diverge, especially that some of them already do that.

We can just ignore the "app version", pretending it doesn't exist.

[jdalton]

We can just ignore the "app version", pretending it doesn't exist.

Yep! That's what I do 🙈

[gibson042]

I'll submit to consensus. But I do think they're setting theirselves up for confusion, since "Edge" corresponds to platform version in User-Agent but app version in the About screen.

[mgol]

@gibson042 Yes, I'd prefer they didn't do that as I indicated above. But we have what we have.

[jdalton]

But I do think they're setting theirselves up for confusion, since "Edge" corresponds to platform version in User-Agent but app version in the About screen.

Yap, we're working on it. The about dialog will take a bit to clear up.

[jdalton]

Should I create a PR to add version info to Edge (totally happy to make time for it) or
can you all tackle it?

[mgol]

@jdalton This is located in our private repo so we'll have to do it ourselves. Thanks for the nudge.

However, first I'd like to wait for BrowserStack to confirm they're going to keep old Edge versions around like they do for Chrome/Firefox and not just keep the latest one (in such a case I'd prefer to not write down the version in our setup as it'll break after an update).

I'd love them to keep older versions, we'd then be able to assert we support current & previous Edge, similarly as we do with older rolling-release browsers. So far we only declare current version support for Edge. (this is on the jquery-3 branch of the https://jquery.com/browser-support/, to be published on https://jquery.com/browser-support/ the day we release jQuery 3.0.0)