Hey Stephen, Thanks for the feedback. Replies inline:
On Tue May 08 23:22:49 GMT-400 2012, Stephen Haberman < stephen.haber...@gmail.com> wrote: > > > 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. > Agreed, but if you have a ton of internal code that is written in such a way that flipping on this behavior causes a ton of failures, then it's going to take time to fix them all. I totally agree that they should be fixed, but it's going to take a non-trivial amount of time. I'd rather spend that time working on SuperDevMode and moving people over to that, where this whole issue of differing implementations between web mode and dev mode goes away. > > > 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. > I completely agree that supporting backwards compatibility all of the time wears on the codebase. However, if you want to suddenly stop supporting this, you need a clean break. Maybe that clean break is defining a new user-level library for GWT; maybe it's SuperDevMode, or something else - but, we do need to define this break at some point soon, and allow for the breaking of backwards compatibility. I'd also agree that we should be less conservative going forward. I just don't think this issue is one where we should start to break backwards compatibility. > 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. > :) That's a much larger discussion. > > 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. > Stay tuned. There are going to be some major changes in the coming weeks that allow for much more flexibility than is currently offered to the external community. To circle back, let's not put this in to 2.5. I do suggest enabling the behavior behind a flag, and we can push people to switch to the new behavior. Internally, we can then tell people the stricter (correct) behavior is going to become the default, and get rid of the flag. Stephen, what do you think? Would you be amenable to adding the code for the flag? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
