On Feb 22, 2010, at 5:48 PM, Ean Schuessler wrote: > 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!
This is another example of why a good separation between the framework and the application code would be really helpful. > 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. Migrating data between versions is a bit of a pain. At least you can compare schemas and see a history of schema changes and such, and hopefully our list of revisions requiring data migration will be maintained well enough for someone to have a one stop place to see what they're dealing with. For custom code or code changes the framework separation would again be really helpful. What I'm thinking is that if we had a really separately maintained and developed framework then it could have real releases and the applications side of the project could stick to one real release at a time. That would mean that the whole project could be migrated from one framework version to the next, and when that is done users would know that is happening and be able to do it with their code too. Anyway, I'm just thinking out loud, I don't know how we'd actually go about doing this with the current community setup and how people normally work with others and the code. Even separating the framework and removing dependencies on the applications so that we could maintain them separately would be a lot of work. I suppose there are other ways of going about all of this, but the ways I'm thinking of would require a different community structure, a lot of volunteer time that probably wouldn't be paid for, etc. And that... I'm not sure on whats or hows there. I've certainly thought about it a lot, and have some of my own ideas, but in thinking I've started to question every principal that OFBiz is based on (which I guess is the only way to really solve problems, ie question assumptions etc). -David
