Appium 1.5
The Appium team is extremely proud to announce the release of Appium 1.5! Go ahead and npm install -g appium while you read the rest of this post!
Appium 1.5 has been in the works for over half a year, and we would like to share why it's such an important release for us. Appium 1.5 is primarily a technical rearchitecture. As the project grew from infancy through to 1.0 and beyond, the core team did their best to keep the code organized, to keep it easy for new contributors to come to the project, and to fix bugs and add features in a timely fashion. However, as is the case with many software projects, the time came when despite our best efforts, Appium's fundamental architecture was working against us, not with us.
Given the relatively stable nature of the project in the 1.4.x series, we felt it was a good time to invest in the future velocity of Appium's development. When we began work on Appium 1.5 we had the following goals:
- Take a hard look at the current code organization and reconceptualize the relationships between different subsections of Appium with an eye to making distinctions clearer and concerns more separate.
- Leverage the NPM ecosystem's best practices and break Appium up into packages based on responsibility, maintenance, etc..., whenever appropriate.
- Rewrite the entire codebase from ES5 JavaScript to ES2015 JavaScript with async/await (and in so doing wipe away a huge source of hard-to-trace Appium bugs).
- Standardize subprocess management. Appium is basically a combination API server and subprocess manager (we manage
instruments, uiautomator, chromedriver, selendroid, etc...), and so standardizing subprocess management makes our code cleaner and more readable throughout the project.
- Abstract common driver behavior: Appium's IOS support and Android support really derive from the same common interface, so we wanted to factor that interface out to reduce duplication of work and boilerplate across Appium's different drivers.
- Clean up our build process so that we are not using a handful of different build tools in different situations. Ensure we're running CI at the subpackage level to save time when releasing Appium.
- Create a more friendly architectural environment for new devs to contribute to Appium. Make sure that one type of change needs to happen in one place and that READMEs abound.
- ...and many more very specific technical goals. For more information on how Appium is now put together from a developer perspective, see our developer's overview.
Importantly, one of our goals was to not add new features, so we could be sure that our rewrite was doing its job without being clouded by the addition of new features. In essence, Appium 1.5 should work exactly the same as Appium 1.4.16, while being brand new under the hood. Of course, we couldn't keep ourselves from making a few tweaks here and there. As a result of the rewrite, various long-standing bugs to do with session handling were fixed, we deprecated a number of server arguments, and added the ability to launch an Android intent via uri. See the full release notes for more details.
Appium 1.5 has been out in beta for several months and we've been actively fixing any issues with it, but being a full rewrite we do anticipate that there might be edge cases not yet uncovered by automated or manual testing, and so we urge caution before use in production CI. That being said, it's ready for you to pound on as hard as you can! Please report any bugs at our issue tracker.
Appium's Future
What does 1.5 mean for the future of Appium? Quite a lot, actually! Despite not having many new features, it is a significant turning point in the history of the project and sets us up for years to come. Here's a few things we're excited about moving forward, based on the work we've done with Appium 1.5:
- Getting more individual and corporate contributors involved in an ongoing basis with Appium development. Now that the code is better organized and written in an easier-to-understand version of JavaScript, we want to actively solicit new contributors. Maybe you? Appium project lead @jlipps recently gave a talk on how to become an Appium developer---check it out!
- Clearing away technical debt so that new drivers may be added swiftly and effectively. The landscape of mobile automation technologies is always changing. Appium wants to be the single API, the single front-end for all of those technologies. We began with Apple's UIAutomation, added Google's UiAutomator and then support for Selendroid. But we won't stop there. Support for Apple's new XCUITest framework is already in beta with appium-xcuitest-driver, and work is underway to add support for Google's new UiAutomator 2 framework into Appium as well.
- Fewer bugs! Far and away the biggest win from the rewrite is moving from an ugly callback-based control flow pattern to the elegant and easy-to-read
async/await pattern. We look forward to fewer hard-to-understand regressions as a result.
- Beginning to strictly follow the SemVer standard of naming releases. We hope you all will agree that having a predictable way to know when it is OK to upgrade Appium versions is more important than following the tradition of saving major version releases for "huge" new functionality. As such, you might see v2.0 or even v3.0 of Appium out sooner than you expect: this doesn't necessarily mean there will have been as many changes as between 1.0 and 1.5---just that we have made some breaking change(s) along the way.
And as always, you can check out our Project Roadmap to see what we're thinking about working on next, and see what we're currently getting ready to release on our milestones page. We are very excited about the future of the Appium Project and committed to its continued development. Stay tuned for what's to come, and as always we welcome your help and contributions along the way!
