That's a good way to sum it up, and exactly right. It's definitely a different task to try to support current users, deprecating features and making slow headway. Technical inconsistency is in an interesting bit; one of the reasons Watir is and always has in my mind been about the api, is similar in intention to something like Cucumber or even RSpec, over Test::Unit.
Our users and our audience straddles roles from newbie tester to developer, but the primary focus is on ease of use for the general tester. I've actually had to back off the list a few times, since while I consider myself a patient person, it can be a bit challenging to work with people who don't seem to help themselves - google, previous postings, bug reports or complaints from QA people who should at least understand the basics of reproducible reports. I would like to work on getting some of the features from Vapir in for the current 1.x codebase, if we can manage to extricate some of it, and then ongoing we can talk about additional features. We also need to get a new release out very soon with activesupport removed, dependency gone and all the current fixes. More of a bug fix although we have a lot of new code in the base. We need to talk about a quick release with a lot of changes, and then the roadmap for additional changes. I realize we can pick and pull from commits, but personally I'd rather we include that in the upcoming release and get on a more regular release schedule. A regular release schedule based on semantic versioning, means we should be able to release fairly often, with the impending quick release which shouldn't break anything for backwards compatibility, so I'd suggest 1.6.6, with 1.6.7 and possibly 1.7.0 coming soon. I'd like to set this one up as the first gem prerelease, and get some feedback so we can start to incorporate that into a more continuous release cycle. I'd like to release a pre of 1.6.6 before the week is out. Anyone in favor? Charley Baker Lead Developer, Watir, http://watir.com On Fri, Sep 10, 2010 at 9:49 AM, Bret Pettichord <[email protected]> wrote: > It seems to me that the reason the Vapir forks exists is because Ethan has > valued a consistent, logical API over compatible support for legacy users > and testsuites whereas the Watir team has been extremely reluctant to > disrupt legacy users even if that means that our API is less consistent from > a strictly engineering perspective. > > Another way of saying this is that we don't really treat technical > inconsistency (which can often create complications for Watir developers) as > a problem until users complain about the inconsistency. A good example of > this is zero-based indexing, which many users have complained about. > > Another Watir principle has been to try to present an API that maps to > casual user's models of a web page, even if that means that it doesn't > exactly map to the DOM. For example, there are several ways to include > buttons in HTML. Watir provides a single API to any of them, where as more > DOM-focused tools (e.g. Hpricot) require users to be more technically > accurate. > > Bret > > On Fri, Sep 10, 2010 at 10:27 AM, Ethan <[email protected]> wrote: >> >> It is true that you can have the second part without the first, indeed, I >> already have the second part without the first (as does watir-webdriver), >> and thinking about that led me to consider deprecating :index. >> True, it will annoy people, but that's always true with API changes - just >> a question of whether the benefits outweigh the annoyance. I think you end >> up with a better API (specifying index as a subscript is more ruby-like and >> doesn't conflate :index with other attributes), and cleaner backend code. I >> think it's worth it. But, this is sort of far out thinking, along the lines >> of deprecating 1-indexing - I wouldn't plan on dropping support for quite >> some time, not until the next major version, at some point significantly in >> the future. >> >> On Fri, Sep 10, 2010 at 09:50, Alan Baird <[email protected]> wrote: >>> >>> My .02 - >>> The first part of the proposal, deprecating :index, is >>> an unnecessary reduction in functionality and breaks backwards >>> compatibility. It would be a pain to update. >>> The second part of the proposal, adding locators to collections, would be >>> a cool feature to have. Of course, you can always use Ruby's select or >>> reject iterator to accomplish this, it's just more wordy. >>> I don't see what deprecating this usage gets you other than annoying >>> Watir's users. Seems like you could do the 2nd part without the first. >>> Alan >>> _______________________________________________ >>> Wtr-development mailing list >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> _______________________________________________ >> Wtr-development mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development > _______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
