Scott Gray wrote: > That's why I was in favor of using deprecation, it's a fantastic form of > documentation. Every time you compile it's there in your face telling you > that you need to change something and what to change it to. > 20 minutes may sound fine, but it's the accumulation of at least years worth > of these types of changes multiplied by the number of people affected by > them. When you look at it in those terms it is a fairly expensive strategy. > I agree. Its also fairly straightforward for use to maintain a list of deprecated items and phase them out as they become more than a release (or two) old. We should try to remember that we are writing for business users and we need to become more conservative about how we approach long-term maintainability. I know that sounds depressing to the code poet in all our hearts but that's what external GIT repositories are for!
Its not hard to imagine a business that hired a group of people to build them a custom OFBiz solution which they now are trying to maintain. If the people who did the job for them did it right then hopefully their custom code is neatly isolated into a component they can just move over. It would be nice if they had a year of warning to put together a team to phase out deprecated bits that look dangerous. Of course, this leaves aside the fact that you need a lot of luck, skill and patience to migrate your data between ofbiz releases but hopefully we can tackle that problem down the road as well. -- Ean Schuessler, CTO [email protected] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
