ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adrian.c...@yahoo.com>
Subject Re: Tossing Backward Compatibility (was Re: What happeded to the real flatgrey theme?)
Date Fri, 21 Jan 2011 05:58:26 GMT
Cool - thanks.

I agree there are a lot of things that can be changed that will improve the project greatly
- but at the same time those changes will break backward compatibility. I'm sure many of the
developers have lists like David's that contain things they would like to change, but they
are hesitant to do so because it might break backward compatibility.

Before this thread gets inundated with developer's wish lists, I would like to suggest that
we address one single simple issue first:

Would you, as an end user of OFBiz, knowing that the OFBiz project could be improved greatly
- but at the cost of some backward incompatibility - accept the changes? If yes, how often
would backwards-incompatible changes be acceptable? David suggested major revisions. Is that
reasonable? Any other ideas?

I'm asking end users - not committers or PMC members (we've already had this discussion).

My experience with the developer community has convinced me that they are open to the opinions
and suggestions of end users. So let's discuss, debate, reach an agreement, and move forward
from there.

-Adrian


--- On Thu, 1/20/11, David E Jones <dejc@me.com> wrote:
> On Jan 20, 2011, at 9:02 PM, Adrian Crum wrote:
> 
> > --- On Thu, 1/20/11, David E Jones <dejc@me.com>
> 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
> 
> 
> 


      

Mime
View raw message