You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pros saved bandwidth for maintainers and the repository itself and a potential higher security for end users in case the repository gets compromised. Cons would be more complex logic inside this repository, the loss of ability to cache the package through composer mirrors like Satis.
It does indeed reduce maintenance burden; though the version matching kinda goes out the window; or would you download the version that matches whatever is checked out, and automate the releases or something?
To clarify further, I think there's another option:
Continue manually releasing & verifying (potential for human error eventually)
Automate downloading the latest version (versions requested in consumer composer.json becomes irrelevant, the next would basically be "the last" release, unless something needed to change)
Use Ocramius/PackageVersions to find out what version of Selenium is requested, and download that. We'd have to automate releases; pick up on a feed of releases, automatically create and push the tag etc. each time somehow. Not too difficult, but I think this is a nice option...
With the list of Selenium releases on http://selenium-release.storage.googleapis.com/index.html it is possible to automate downloading the Selenium server standalone binary at composer install.
Pros saved bandwidth for maintainers and the repository itself and a potential higher security for end users in case the repository gets compromised. Cons would be more complex logic inside this repository, the loss of ability to cache the package through composer mirrors like Satis.
What do you think @asgrim?
The text was updated successfully, but these errors were encountered: