Skip, I know what you are talking about, I had my share with a part of Opentaps adaptation for https://issues.apache.org/jira/browse/OFBIZ-4247 So believe me, I'm very cautious when deprecating stuff.
BTW you said that "Things are about 20% slower." Where, in which areas, did you cross this? How did you measure? Jacques Skip wrote: > Jacques > > Being nearly done with this and my frustrations long since passed, I have > only a couple of things to say about this for future development. I have > been writing developer software for multiple decades and found from > experience that backward compatibility is your most important concern. > > No one should ever change stuff just because they do not like wording or > style. For example, there were wholesale changes to the xsd for widgets. > There was no real benefit to the change other than readability. It should > never have been done. Instead, both words should have been supported. For > me, this required days and days of search and replace for no value. > > Another is the replacement of new EntityExp() with > EntityCondition.makeCondition() etc. Someone decided that they liked this > better. That is the only possible reason for the change because the > underling code could have supported either or both APIs. This kind of stuff > is unforgivable in my view for developer software and that is what ofbiz is. > It has very little value OOTB and requires developers to give it life. Some > of us have thousands of other files written to these apis and to force us to > change them for no real value is frustrating to the maximum. > > Finally, the change in the password hash is the most agreggious example in > my view. It would have been a simple matter to use both (or in this case > all three hashing methods). When a password changes, use the newest, best > method, but allow the existing hashes stored in the database until changed. > I modified the ofbiz code to do exactly that and it works fine and took me > all of an hour once I spend several hours tracking down the problem. > > As Ofbiz contributors, I am sure you guys wear two hats. One as an Ofbiz > contributor and one as a developer using Ofbiz for end users who actually > pay you. As you make changes to Ofbiz code to implement something a > customer really wants, remember to not screw the hundreds (thousands ?) of > other Ofbiz developers who depend on it like you do. > > Backward compatibility is or should be your most important concern. Just > take a look at the compile log for Ofbiz and see how many deprecated Java > methods we still use. Then, look at how long they have been deprecated. > Some for decades. > > Thanks for all you do. > > Skip > > -----Original Message----- > From: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] > Sent: Saturday, September 14, 2013 10:01 AM > To: user@ofbiz.apache.org > Subject: Re: FW: Mirgration to OFBiz newer version > > > Pierre Smits wrote: >> Jacques, >> >> Updating (or migrating) is determined by various factors. Each update >> brings risks and cost. Especially with a system in production. The >> (perceived value of the) improvements must weigh against the cost involved >> in implementing. >> >> I thank Skip for sharing the experience. I will surely use it as part of >> my migration plans. As far as I can go back it is the first time that it is >> done. Sharing implementation and upgrade experiences builds confidence. It >> should be encouraged. >> >> What worries me though is the experienced decrease in performance. > > This would need much more measures to know what we are talking about... > >> With kind regards, >> >> Pierre Smits
