Closed apsdehal closed 8 years ago
I am going to be helping out on this. Documenting my requirements here for completeness, though it goes beyond the scope of the original request.
Version math. This means being able to say latest - 1
, latest - 2
, etc. to keep up to date while still supporting slightly older versions that are still in the wild. I don't see any need for +
or other operators.
Version ranges. For example, Internet Explorer 9 - 11
, Chrome 45 - latest
, etc. to succinctly represent more than one or two configurations that are otherwise the same. The DRY mantra applies here.
I'm not sure whether using different syntax for each vs just treating latest
as a special case would be more intuitive (can't think offhand of any time you would start a range with latest -
). If the above looks ambiguous, ranges could use 9..11
, 9 to 11
, etc.
An easy way of dealing with some of this would be to embrace actual semver, which many Intern users will already be familiar with. The browsers don't even have to be compliant for this to work well. However, I don't believe it has a way to say latest - 2
.
Also consider SauceLabs Selenium version spec. They support latest - x
now as a standard capability.
Note that we can already do version ranges in a sense by specifying multiple versions in an array for version
.
If by semver you mean npm's version ranges, I could see that being potentially useful. Is it common for people to want to test ranges of more than a couple browser versions, or more than a couple that aren't contiguous with 'latest'?
By 'consider SauceLabs' I just mean that they have a syntax for this now, so it may be good to follow, particularly since it would basically be a pass-through for the SauceLabsTunnel.
Also consider SauceLabs Selenium version spec. They support latest - x now as a standard capability.
Yeah, BrowserStack has something similar. Would be nice to see a standard across providers, but I'm not holding my breath. :)
Note that we can already do version ranges in a sense by specifying multiple versions in an array for version.
This works well for some things. But it breaks down when it comes time to say Safari 6 - latest
, etc. I want to pick up new versions of Safari automatically, but support a minimum version.
If by semver you mean npm's version ranges, I could see that being potentially useful. Is it common for people to want to test ranges of more than a couple browser versions, or more than a couple that aren't contiguous with 'latest'?
This is probably more of a power user case, but yeah that's happened to me on enterprise applications now and then. We need to support a slew of installations, but some new browser comes out that breaks things and it takes us a while to respond with a real fix. In the meantime, we can't support anything past a certain version.
Howdy,
I have a work in progress supporting 'previous' and 'latest' version aliases on my digdug fork. It should be pretty straight forward to extend it to use latest-x nomenclature. Please have a look.
Tunnel: https://github.com/devpaul/digdug/blob/version_alias/Tunnel.js#L559-L573
SauceLabsTunnel: https://github.com/devpaul/digdug/blob/version_alias/SauceLabsTunnel.js#L461-L472
BrowserStackTunnel: https://github.com/devpaul/digdug/blob/version_alias/BrowserStackTunnel.js#L270-L323
Yeah, BrowserStack has something similar. Would be nice to see a standard across providers, but I'm not holding my breath. :)
Browserstack's only works with their JS provider, which uses some BS-specific APIs to get information about available browsers. Sauce's works through the standard Selenium capabilities interface, which is much more convenient (for us). However, Sauce's implementation won't work for ranges, so in that respect it really doesn't buy us much.
I want to pick up new versions of Safari automatically, but support a minimum version.
Makes sense.
So maybe we just need 2 syntaxes, at least for now, something like 'latest - x' and 'version1 .. version2' (e.g., '6 .. latest - 1')?
I'm updating the code to support a more complex set of ranges, aliases, and math.
Supported version types and ranges:
Sweet. :)
Personally, I don't think previous
should be a thing if we have math. It's not shorter, or clearer, or any other benefit I can see. But it is more to support and maintain, document, etc. Just my two cents.
Personally, I don't think previous should be a thing if we have math. It's not shorter, or clearer, or any other benefit I can see. But it is more to support and maintain, document, etc. Just my two cents.
Since we are already supporting latest
it is trivial to support previous
. It occupies 2 lines of code and it may be useful for those who wish to explicitly list versions without using ranges.
environments: [
{ browserName: 'firefox', version: 'latest' },
{ browserName: 'firefox', version: 'previous' },
]
If somebody wants to use previous
, especially if they've used it in other contexts, I'm ok with that.
Fair enough. Just my Python background peeking through. :)
Hmmm...I agree with @sholladay regarding 'previous'. In general, Intern prefers to have only one way to do things.
This has been added in commits 96aa488 and theintern/intern@ab9a245. Thanks @devpaul! It will be included in the next releases of Dig Dug and Intern.
It would be good if one can specify
latest
andprevious
version for Browserstack tunnel to reference the current and previous versions for the browsers available on browserstack. This feature is available in browserstack-runner as of now: https://github.com/browserstack/browserstack-runner#compact-browsers-configuration