I'm totally in for frequent release cycles! Currently it seems to be like some enterprise application :/
Also, incorporating (some or most of ) Ethan's changes into Watir would make sense also. I don't believe that it's not possible to chunk those changes into smaller parts even if they're changing core. Ethan, could you explain why you've stated something like that before? I mean, you didn't fork Watir and then work one year in a row and then made one gigantic commit with all files changed-added-deleted, did you? Any other reasons why you've stated something like that before? Jarmo On Mon, Sep 13, 2010 at 9:58 PM, Charley Baker <[email protected]> wrote: > 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 > _______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
