Doing migrations one step at a time

[Brian Slesinsky]

Following up on discussion in: https://gwt-review.googlesource.com/#/c/2900/

There's been some talk about dropping IE 6/7 and it's confused the conversation a bit. I'd like to distinguish between what happens short term and how things will look by our next stable release. I expect that by GWT 2.6, IE6 and 7 support will be gone. People who use stable releases have opted in for big-bang, everything changing all at once and they can do it on whatever schedule is convenient to them, including not upgrading until they're ready.

Short-term for those of us at trunk, it's a whole lot easier if we take it one step at a time. First add the new stuff, perhaps hiding it behind a flag. Turn it on by default. Then remove the old stuff. If these land as separate commits then we can verify that each one didn't break our customers before moving on to the next. I realize it's more work than a single atomic change, but it's a lot smoother.

I'm fine with waiting on some patches until IE6/7 goes away entirely, but it's also possible to move a few steps forward on some things without waiting on a different patch.

At the moment, I don't know anyone specifically working on removing IE6/7, which should proceed in a similar way. We've agreed that it should be done, but someone has to do it, and I'd expect it also to go one step at a time. I think the first step is to make sure everyone knows how to enable or disable the IE6/7 permutation (are any code changes necessary?), and the next step is to change the default so it's off.

- Brian

[Thomas Broyer]

Does Google still support IE6/7 on some apps? I thought you only supported IE9+

If you don't support IE6/7, and we choose to drop IE6/7 support in the next release, then 'master' could have a transition period where RPC simply wouldn't work in IE6/7 without removing the ie6 permutation.

BTW, disabling the IE6/7 permutation is only a matter of <set-property name="user.agent" value="ie8,ie9,gecko1_8,safari,opera"/> right? Removing support would start by removing the ie6 permutation and then cleaning up the code by removing now-unused code, and finally possibly clean up further by refactoring some code that was used in both ie6 and ie8 to better take advantage that it'd now only be running in IE8.

I otherwise agree about the principle: first deprecate, add a flag, then turn the flag off by default and remove the code then remove the flag (or remove everything in one go). Well, anyway, that's the basis of trunk-based development which is what we chose to use for GWT.

[Brian Slesinsky]

On Fri, May 24, 2013 at 5:53 PM, Thomas Broyer <t.br...@gmail.com> wrote:

On Saturday, May 25, 2013 12:57:09 AM UTC+2, Brian Slesinsky wrote:

Following up on discussion in: https://gwt-review.googlesource.com/#/c/2900/

There's been some talk about dropping IE 6/7 and it's confused the conversation a bit. I'd like to distinguish between what happens short term and how things will look by our next stable release. I expect that by GWT 2.6, IE6 and 7 support will be gone. People who use stable releases have opted in for big-bang, everything changing all at once and they can do it on whatever schedule is convenient to them, including not upgrading until they're ready.

Short-term for those of us at trunk, it's a whole lot easier if we take it one step at a time. First add the new stuff, perhaps hiding it behind a flag. Turn it on by default. Then remove the old stuff. If these land as separate commits then we can verify that each one didn't break our customers before moving on to the next. I realize it's more work than a single atomic change, but it's a lot smoother.

I'm fine with waiting on some patches until IE6/7 goes away entirely, but it's also possible to move a few steps forward on some things without waiting on a different patch.

At the moment, I don't know anyone specifically working on removing IE6/7, which should proceed in a similar way. We've agreed that it should be done, but someone has to do it, and I'd expect it also to go one step at a time. I think the first step is to make sure everyone knows how to enable or disable the IE6/7 permutation (are any code changes necessary?), and the next step is to change the default so it's off.

Does Google still support IE6/7 on some apps? I thought you only supported IE9+

Depends on the product. I see that Adwords is dropping IE8 soon:

  https://www.en.adwords-community.com/t5/Ad-Approvals-and-Advertising/Google-Ads-cease-support-for-Internet-Explorer-8/td-p/133766

Can't find it for Wallet but it says IE7+ for the API:

https://developers.google.com/commerce/wallet/digital/faq#faq-technical-02

 

If you don't support IE6/7, and we choose to drop IE6/7 support in the next release, then 'master' could have a transition period where RPC simply wouldn't work in IE6/7 without removing the ie6 permutation.

BTW, disabling the IE6/7 permutation is only a matter of <set-property name="user.agent" value="ie8,ie9,gecko1_8,safari,opera"/> right?

Perhaps. There was some talk about having a trivial permutation that just shows an alert if your browser is unsupported. We never had that before, though.

- Brian

[John A. Tamplin]

On Fri, May 24, 2013 at 8:53 PM, Thomas Broyer <t.br...@gmail.com> wrote:

BTW, disabling the IE6/7 permutation is only a matter of <set-property name="user.agent" value="ie8,ie9,gecko1_8,safari,opera"/> right? Removing support would start by removing the ie6 permutation and then cleaning up the code by removing now-unused code, and finally possibly clean up further by refactoring some code that was used in both ie6 and ie8 to better take advantage that it'd now only be running in IE8.

Yes, and maybe we should go ahead and do that immediately -- leave all the support for ie6/7 in place, but just don't build it by default.  If anyone is running from trunk and needs it, they simple add it back with an <extend-property>.

--
John A. Tamplin

[Thomas Broyer]

Isn't there gwt:onPropertyErrorFn already for that use-case?
We need to document it though:
https://code.google.com/p/google-web-toolkit/issues/detail?id=8135

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[stuckagain]

Just my 5 cents,

 

Decisions on browser support seems to be mostly driven by Google statistics ... but many GWT apps are running outside of the internet. The apps that I am maintaining and developing run in a banking environment, where the browser usage statistics are a lot different - IE8 is the king, Chrome is nearly non existant and FireFox is growing. Most banks are very reluctant to switch browsers because they have a lot of software strictly qualified to a specific version and Windows does not allow co-instalation of multiple versions of IE. (Chrome and FireFox is a differetn discussion, but most banks do not use those right now).

 

Banking is still one of the bigger markets of software development, so somehow I hope you want to consider supporting IE8 in some form in the near future. I guess until 2014 seems like a reasonable timerange. for us, but certainly not faster.

 

David

[John A. Tamplin]

On Mon, May 27, 2013 at 4:40 AM, stuckagain <david...@gmail.com> wrote:

Decisions on browser support seems to be mostly driven by Google statistics ... but many GWT apps are running outside of the internet. The apps that I am maintaining and developing run in a banking environment, where the browser usage statistics are a lot different - IE8 is the king, Chrome is nearly non existant and FireFox is growing. Most banks are very reluctant to switch browsers because they have a lot of software strictly qualified to a specific version and Windows does not allow co-instalation of multiple versions of IE. (Chrome and FireFox is a differetn discussion, but most banks do not use those right now).

 

Banking is still one of the bigger markets of software development, so somehow I hope you want to consider supporting IE8 in some form in the near future. I guess until 2014 seems like a reasonable timerange. for us, but certainly not faster.

At the GWT meetup, there wasn't really consensus on anything regarding IE8 other than not before 3.0 next May.

--
John A. Tamplin

[Thomas Broyer]

Note that, just to make things clear for everyone, removing the ie6 permutation means removing support for "IE8 in IE7 mode" and quirks mode (this one has been discouraged, if not deprecated, for years now).

This is a step forward and, if you ask me, I don't care about those companies that don't get "the Web" and live 5 years in the past: if they're OK with that, they won't mind being stuck to GWT 2.5.1 or 2.6. Otherwise, GWT is open source, they can fork it and backport fixes from future versions (and in the unlikely event they "get OSS", they can make the fork public and grow a community).

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/NWyaRsfy0-Q/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brian Slesinsky]

Some companies have slow upgrade cycles but we can still have sympathy for the developers who work for them. But I agree that since upgrading GWT is optional (for those using stable releases), we shouldn't have to worry about them too much.

Note that Microsoft stops supporting Windows XP next year [1] and Windows 7 shipped with IE8.

[1] http://www.microsoft.com/en-us/windows/endofsupport.aspx

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.