I've been doing a lot of thinking and planning for what we need to do with Watir. I've also been fairly quiet. I now have a new job and have been preoccupied by the change in jobs lately: with wrapping up affairs at my old job at DataCert, with a job search, and then with starting at Dovetail, where they had built up a bit of a backlog of work for me which I've finally dug out from.
Dovetail has made a big commitment to Watir: to using it to test our software, to supporting enhancements that we will be using, and even to giving me time to attend to the necessary affairs in running an open-source project. In fact, Dovetail intends to ship our testing framework and our tests themselves to our customers. This means that our tests will need to be good: be easy to understand, extend, run and interpret. I am very excited by the opportunity. Watir 1.5 is getting very close to being "done." As soon as it looks like we've fixed all the serious compatability bugs with Watir 1.4, we will be posting the 1.5 gem to Rubyforge. This means that it will become the default gem that will be installed when you do a "gem install watir". Originally I wanted to wait until we got the documentation for 1.5 updated, but now now i think that can wait for a later point release (say 1.5.3). Charley tells me that many of the questions on the wtr-general list regard problems that would be solved by moving to 1.5, so it really will help to move there. By the way, Charley has also been rather busy lately, partly because people keep hiring his Watir testers away from him. So if you are one of these people, stop it. It only hurts Watir, in the end, by forcing him to spend all his time on his day job. Jeff Fry is threatening to help out with the Rdoc and Zeljko has agreed to take the lead with updating the users guide. Please cooperate with any requests that they make. Many of you have noticed that FireWatir is looking very good. SafariWatir is also looking good. The number one goal that I have for Watir is pull together these different forks of Watir. In my view they should all be part of one library, or perhaps each will be a plug in to a standard library, much as, say the Ruby DBI library supports plug ins for each of the different types of databases. In our case, we'd have separate plug ins for each browser. This means supporting multiple browsers and making Watir work on multiple platforms. The importance and complexity of this goal is part of what is urging me to wrap up Watir 1.5. We are targeting Watir 2.0 to include plugins for each of the main browsers. I also plan to continue working on a Selenium plugin to Watir. This would allow existing Watir tests to run tests using any browser when connecting to a Selenium-enabled server. This, like all the browsers, will be optional; so if Selenium scares you, you will be able to continue to use Watir the old-fashioned way. In preparation for this, Watir 1.6 will begin the restructuring of the existing code base to support plugins and remove the code duplication that currently exists in the different forks. This will require reorganizing the code files, and therefore we will want to merge all patches before this reorg starts. We will also be taking this occassion to make many changes to Watir that we've been considering for some time, but have put off because of concerns about backwards compatibility. We have attempted to make upgrading from 1.4 to 1.5 extremely easy. Upgrading to 1.6 will be more difficult. In particular, we will be converting Watir to use zero-based indexing in 1.6. Another key element to getting Watir 1.5 out is updating our website. We will be publishing a new, detailed, multi-page website aimed at our general user community. This website will be hosted at wtr.rubyforge.org and will include current information about the various releases and how to install them and where the mailing lists are. And we'll be keeping it up to date, as we move forward with this plan. We will continue to use the wiki at OpenQA for the active user community and there will be several links from the general website into the wiki. We have had a lot trouble keeping the various pages on the OpenQA website updated and accurate and will be replacing them with pointers either to the website or to the wiki. I realize that the current arrangement is very confusing and appreciate your patience. The Jira roadmap more or less lays out the next few steps in our plan. We will be updating it shortly to better match up to the plan I lay out here. If you have bugs you want fixed or features you want added, please make sure there is an open Jira ticket for them. Bret _______________________________________________ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general