> I agree, but asking anyone to have to make changes in working code Two things, one is that I don't think any code that relies on this behavior could really be called "working". It's dev mode mistakingly acting differently than web mode.
> as a consequence of upgrading increases the cost, even if they are > good changes. The other is that (disclaimer, this isn't really a discussion for the bug tracker, and is just my personal opinion) I think this extreme dedication to backwards compatibility at some point hurts more than it helps. Yes, it means users have 0-change upgrades, which is great if you do an upgrade every month (or on every commit, e.g. internally to Google). But after years of 0-change upgrades, I think the burden of backwards compatibility starts to wear on a codebase. Of course every release can't be a fresh start, but I think there needs to be a compromise that's less-than-every-release but more-than-never. Furthering my musing that is kind of silly to do in an issue, I think Google's internal "all upstream/downstream projects always build from trunk" encourages codebases to grow stale as they can never break any project ever. Let's have some forks, branches, or something, that at least occasionally lifts this burden of backwards compatibility for those of us who are just fine with a yearly-ish/non-bugfix release that has breaking changes in the name of a better, cleaner codebase. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
