Sorry, didn't see that part of your mail: On Monday, January 14, 2013 5:43:36 PM UTC+1, [email protected] wrote: > > > Perhaps you have the resources to fully regression test all of your > applications every week on all 8 or 9 different supported browsers, plus > dev/beta versions, but in the real world of enterprise software, that's > simply not feasible. >
I don't have those resources, but I'm aware that it's what I should do. It's actually even worse: I'm paid to build webapps, not maintaining them. We're not proactive on browser changes because that's not part of the deal with our customers, but we're generally in the situation of shipping a fixed version (provided there's an easy fix or workaround) in a matter of hours. Once the warranty period is over however, I bet nobody does testing either and fixes can take ages. BTW, I also know there *are* people in the "real world of enterprise software" who *do* end-to-end testing, either using Selenium/WebDriver on a cluster of servers, or using SaaS such as Sauce Labs, driven by a CI server (Jenkins/Hudson, TeamCity, Bamboo, etc.) to be run on each commit and/or nightly. The root of the issue is that most people (IT deps mostly) ask for webapps rather than native apps (generally to replace native apps) for bad reasons and/or without understanding the consequences. > Stable software should remain stable. If a customer upgrades his version > of Windows, I shouldn't expect the new version to suddenly start working > strangely because of a radical change in how animations are rendered. A > similar concept should apply for web browsers. > ROTFL! Are you talking about that Windows OS that breaks its WebDAV support in almost every new version or service pack, and even sometimes hotfixes? http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html (I had to do an emergency patch in a server after the SP1 was deployed on Win7 this fall; BTW the webapp is 4 years old 'cause nobody allocated the budget to maintain and update it, not even with security fixes: “if it ain't broke, don't fix it”, BS; this is the state of software in the "real world of enterprise software": zombie servers on a drip of emergency fixes to keep them alive) The one OS for which every IT department delays hotfix/SP deployment by fear of breaking their payroll or LoB apps? (which is probably the main reason there's still so many IE7 and IE8 out there –last year I would even have added IE6 to the list–). But again, we're talking here about a bug in GWT, in the use of a "beta" API. And that bug was fixed long before the change in Chrome reached end users. Also note that in a closed environment (intranet) running Windows, you can disable Chrome and/or ChromeFrame auto-updates using a group policy. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/TrXgVE-yio0J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
