Re: The Chrome 24 Animation bug and unstable APIs in general

Even better than a command line switch would be a deferred binding switch. Then you could compile and deploy something with and without experimental APIs at the same time. If something breaks you can tell customers to switch to using a different host page that uses the version compiled without experimental APIs.

Paul

On 30/01/13 15:19, Andy wrote:

It sounds like our situations are fairly similar and we'd both benefit from having the most stable foundation possible. I'm still happy with a switch defaulting to using experimental apis, but I'd love to have a switch there.

The release cycle of Chrome is much more frequent than the effective release cycle of our software. While we might release as or even more often as Chrome, what really matters is when that release is deployed and that lengthens the cycle. What this means is that the code we ship today needs to work with the next 6 versions of Chrome. There's nothing I can do--other than be careful about the apis I use and trust that Chrome will maintain backward compatibility--to test and prepare for the next 6 versions today. Experimental apis don't come with the promise of backward compatibility, so I consider them off limits unless absolutely necessary.

Thank you for your perspective and all of the work you do with gwt.

-Andy

On Wednesday, January 30, 2013 8:48:41 AM UTC-5, Thomas Broyer wrote:

On Wednesday, January 30, 2013 4:11:41 AM UTC+1, Andy wrote:

Thanks Thomas. Another great discussion, but I'm really surprised by all of the enterprise software hate.

Obviously, the core issue is that too many people don't get the Web, but that's another debate.
Of those people, who came complaining in the forum, some said they couldn't even recompile their app with the workaround (i.e. we're not even talking about updating to GWT 2.5 here, which would imply going through non-regression tests, etc. just applying a small workaround, recompiling and redeploying).

As I said, we sell software that is compiled by GWT and deployed behind firewalls within organizations. We can recompile and post patches, but it's up to them to redeploy. They might not see that code for 6-12 months in some cases depending on their policies. To give you a sense of the challenge, many of them are still using IE7 as their primary browser, but of course those people weren't affected.

You might argue everything web should be SAAS, but many of our customers aren't going there and have good reasons.

That's not what I'm saying.

In your case, you're an editor so you have the responsibility of testing your app with beta/dev versions of browsers before they reach your customers, and if you find an incompatibility then you tell your customers to update their installs of your app with the version that contains the fix/workaround. It is then the responsibility of your customers, if they'll be affected by the issue, to deploy the new version or prevent their browsers from updating: they chose to install/use a webapp, they should be prepared to deploy such "patched versions". As you said, "it's up to them", and they then have no reason to whine if they're not up-to-date: you gave them a fix in due time (possibly even before they'd notice the issue).

What I'm angry about is a bit different though: our customers ask us to develop a webapp (we're not an editor, it's their app, they own it and are responsible for its maintenance). Once deployed in production, they only care about the server being up and running; they update their browsers but don't plan for (preventive) maintenance of their apps (it holds for any app, not only webapps, but webapps exacerbate the problem). Far too many people don't even monitor their apps for security breaches: only a handful of our customers ask us the list of 3rd-party products/tools/libs we've used to build their app, and even less monitor them for vulnerabilities.

It's no different from your customers not installing updates, except that they probably pay you a license or other commercial support that includes providing updates; in my case, once we deliver the app nobody does the preventive maintenance. During the warranty period we fix those issues (we might update vulnerable dependencies too, but it's not even part of the deal), but once it's over it becomes our customer's responsibility, and nobody does it (unless it's a LoB app, maybe). We have support contracts in some cases, but it's only about fixing bugs (and sometimes adding features); preventive maintenance is not part of the deal.

You just can't let a piece of software live its own life, particularly when it's a distributed app, even more if it's a webapp (because you have even less control over the "client runtime environment", i.e. the browser)

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.