On Jan 20, 2011, at 9:02 PM, Adrian Crum wrote: > --- On Thu, 1/20/11, David E Jones <[email protected]> wrote: >> What the project needs is cutoff points at major revision >> releases after which attempts at backward compatibility are >> totally abandoned in favor of making something better. > > Why don't we discuss that further? Perhaps in a new thread?
Okay, here's the new thread. To kick it off there are probably lots of facets of this to discuss, but the biggest question (IMO) is: what will we get rid of? Another way of looking at that is: how will we decide what to get rid of? This gets even trickier as time goes on and new things are introduced that are alternatives to old things. One example is the FTL macro based widget renderers... the old ones can go away. Another would by the Query Builder that Scott was working on (OFBIZ-4053), and that could result in getting rid of a bunch of stuff in the Delegator and GenericDelegator. There are also hundreds of methods that simply the same as another method in the same class but with fewer arguments and defaults for the missing arguments, and tons of those can and should go away (many are there for backward compatibility only). But is any of this really doable in OFBiz given desires and priorities of the community? Heck, we have complaints about EVERYTHING. Constant complaints about every little change. If all of the delegator.find* methods are suddenly gone... just imagine the complaints (well, not to mention the refactoring of code in OFBiz itself!). We have complaints about formatting changes in code. We have complaints about any and all refactoring changes (moving code, renaming, splitting up or combining methods or classes). What about getting rid of the dozens of totally useless util classes in OFBiz? Most of them could (and maybe should) be tossed in favor of other open source stuff, or even better in favor of new features in Java or that are handled inherently in Groovy or other tools used a lot in OFBiz. How about making things more consistent in OFBiz by using groovy for all expressions and such? We could get rid of the BSH defaults, the UEL stuff, and so on. Yeah, I know a lot of work has gone into these things... but consider the state of things now and the pain involved in using some of these cumbersome tools. Of course, is this even doable... and worth it? Could we even retest all of the code that would be affected by these lower level changes? Could we do this without huge efforts in branches? Because the framework and applications are tied together we can't easily advance the framework freely and then once we like it do a feature freeze and start getting the applications/etc to catch up. Stepping back I guess the real question is: can we even do these sorts of things at this point in the life of the project? The jQuery branch is an interesting example. I think that worked because it was a change with relatively few touch points, and only a couple of people were interested in it so everyone else left them alone while they worked on it. But what about bigger changes that result in a need for changes in thousands of lines of existing code? -David
