As we move forward with the project plan of standardisation of the API,
 issues like this are going to be more of a browser issue.
 
If we do see issues like this, and the browser vendor owns the
 implementation like with Google Chrome, should we hold up a release? I for
 one would be extremely against that. So am -1
 
At the moment we are roughly one weekly releases so unless it's a total
 blocker, and as in the build is red, we should carry on as normal. Everyone
 with the commit bit should run tests as often as they can so we may be
 aware of issues.
 
David
  On Nov 10, 2011 5:34 AM, "Tarun K" <tkum...@gmail.com> wrote:
 

- Show quoted text -

* Also sprach Daniel Wagner-Hall <dawag...@gmail.com>:
 
> I'm not sure what this gains us in a world where every older version
 > is available. I believe the current mechanism is as you describe, with
 > one additional step: if users have issues, they down grade until the
 > issue is resolved. This may be annoying for them, but it's also a
 > workable solution, and means that we have more users doing that
 > testing.
 > As we've moved to ~weekly releases, I'm sure a lot of people are also
 > just skipping some updates, too.
 


I agree pretty much agree with what's being said here.
 Maintaining different release channels for Selenium would be _a huge_
 undertaking considering the complexities of this project.  Considering
 that we're not pushing Selenium to any package management systems for
 OSes, this is a workable solution.
 
But:
 
I'm unsure what the “@Beta” thing means in all of this.  Does it mean we
 will continue to maintain and release important fixes for the stable
 (previous) version, effectively introducing two release channels?  Or
 does it mean the users will just have to upgrade to the latest bleeding
 edge to get patches for bugs?
 
This sounds suboptimal to me.  I realize that Selenium is not an
 ordinary project and cannot offer the same LTS release schemes as other
 traditional software (like in the traditions of Debian) without major
 effort, and frankly there is no need to do so for the core project
 either, but there is a chance we'll be communicating things less clearly
 by separating between final- and beta versions.
 
I'd personally like to see Selenium reach such a stable state that a
 user wouldn't have to upgrade in between minor (x.Y.z) releases, but
 with things moving so fast within the browser automation world, I
 realize that might be a far stretch.
 
I'd like to hear the reasons for introducing “@Beta”, as it seems to me
 that Daniel Wagner-Hall's described approach above (“if things doesn't
 work for you, please downgrade and use the previous version until we get
 time to fix it and release a newer version”) seems more than adequate to
 me.  It's true that this isn't optimal in terms of user-friendliness,
 but then this is all just really a symptom of our testing environment
 not being good enough.
 
Whenever we catch a bug like above, we should actively be finding ways
 to test for that in the future.  That said, we also need to make it
 easier and more stable to run the full stack of tests.  Or, in the
 least, ensure that our CI environment is functioning correctly.
 
Thanks!!
 
--
 Andreas Tolf Tolfsen
 Systems Developer, Core Systems
 Opera Software ASA

It's definitely dev's call.
 And chrome driver may be one long running exceptional issue. But I hope we
 want users to upgrade to new release every week (or so). And not keep going
 back to previous release because of some issues.

You don't know it, and won't necessarily agree given I'm pointing it out,
 but you're making a case for better regression tests before release. Only.
 
- Paul
 
On Tue, Nov 15, 2011 at 9:18 AM, semperos <daniel.l.grego...@gmail.com>wrote:
 

- Show quoted text -