[RFC] Name of the driver

[stof]

Currently, the driver is named Selenium2Driver. But this driver is not really about Selenium 2 only. Currently, it is also about Selenium 3. And with #293, it would also be about the W3C Webdriver protocol, which is not related to Selenium itself (except for the inspiration).

In the new world, Selenium might not be involved at all in the stack now that Webdriver is a standard implemented by browsers directly, and Selenium is only the intermediate node for grid support (if we except Internet Explorer support, which is still provided by Selenium and might speak only the legacy protocol).

Should we have it as WebdriverDriver instead ?

What do you think @aik099 ?

[stof]

Note that starting a new repo might be the easiest way to change the name in case we decide that the right path for #293 is to change our dependency.

[aik099]

Shouldn't be WebdriverDriver be WebDriverDriver instead?

Otherwise I'm ok with a renaming. I see 3 ways:

1. rename repo on GitHub, but keep Packagist package name (keeping same name on Packagist is preserving BC, but defeating purpose of whole rename)
2. rename repo on GitHub and abandon current package in favor of new Packagist package (does that allow us to rename classes inside repo itself?)
3. having another repo + another package as if it was a new driver and advertising to use new package instead (would be a mess with currently opened issues/PRs, because whoever submits the issue/PR needs to figure out correct repo)

[stof]

@aik099 if we rename it, the package and the code should be renamed too.

The strategy (2 or 3) will depend how different the code is with the facebook webdriver library, to see whether it is worth keeping the history, or whether starting from scratch is cleaner.

Strategy 2 allows to rename classes if we do a major version bump

[aik099]

Then we're good to go. Not sure about currently opened issues/PRs. If we'll create another repo, then what will become of them?

[stof]

3\. (would be a mess with currently opened issues/PRs, because whoever submits the issue/PR needs to figure out correct repo

I think having another repo for the enw package would be less of a mess. The new driver implementation would be a full rewrite, so all currently opened issues would be irrelevant for it.

[stof]

Regarding the name, the W3C spec is indeed WebDriver and not Webdriver.

The only issue with that name is that Mink\WebDriverDriver and mink/web-driver-driver look a bit weird.

For the package name, maybe we can use mink/webdriver-driver.

[stof]

@aik099 what do you think about Mink\WebDriverDriver (or maybe Mink\Driver\WebDriverDriver if we decide that our drivers should not be directly in the Mink namespace if we ever want to migrate away from Behat\Mink in the future for the core ?) and mink/webdriver-driver ?

[aik099]

If there is no other way and DriverDriver (repeated word looks weird) should be used, then I have no objections.

[mparker17]

FWIW, I'm in favour of:

• Option 3: starting another repo and another packagist package as if it was a new driver and advertising to use new package instead
  • I agree this would be less of a mess
  • I daresay a new package would make it easier for downstream projects to add support for WebDriver without breaking things for users who still have their own tests, contexts, etc. that depend on assumptions only in Selenium2 (I work with Drupal so I'm thinking of the Behat Drupal Extension in particular, which has two steps which depend on `getStatusCode() - and I've used this step many times over several older projects)

I'm weakly in favour of mink/webdriver-driver for the repo name and Mink\WebDriverDriver for the package name (they look fine to me) - but I'm happy with whatever we decide.

---

FWIW, I have a mostly-complete (although no tests yet!) Driver (i.e.: a class that implements Behat\Mink\Driver\DriverInterface and a handful of helper traits/classes) that I wrote so that I could run Behat tests through Mink through the Behat Drupal Extension through the php-webdriver/webdriver project and browserstack/browserstack-local-php to send WebDriver1 commands to BrowserStack's "Automate" WebDriver endpoint from CI... I daresay much of this could be adapted into a Mink WebDriver Driver project, but currently I'm not sure where to start patching.

[stof]

Closing this as we have setted on mink/webdriver-classic-driver for the new driver, and we implemented it as a new package instead of a new major version of this package.