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:[email protected]] Sent: Saturday, September 14, 2013 10:01 AM To: [email protected] 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
