I have a friend who's favorite business saying is "start out where you want to end up". It is sort of a nonsense phrase but it says something similar to "a stitch in time saves none". If we are clear about what we are trying to build it will be much easier to put those fixes in now than to try to change course down the road.
In my mind, we are trying to do something revolutionary which is to bring the power of ERP down to the small to medium size business player. Its revolutionary because, if successful, it has the potential to change the dynamics of business and the structure of the world economy. If we are going to succeed in that task we are really forced to confront the reality of what those business owners need. That means providing business continuity even in the face of small budgets and a minimal IT staff. If we can make the "myth" of easy upgrades a reality then our software it going to be much more widely adopted. I'm not trying to brush the complexity of this under the rug. I agree with you whole-heartedly that seamless upgrade-in-place is probably a real pain for us to achieve. At the same time, it also has the possibility to reduce our overall workload. Adam and I personally have to oversee upgrading customer installations on a regular basis and those upgrades are typically time consuming and a little bit scary. If this problem was reduced to literally pushing a button it would free up time that could be spent on more productive tasks that actually improve the customer's business. My $0.02. ----- "Jacopo Cappellato" wrote: > In rev. 930182 I have created also the upgrade script to migrate data from > old to new fields. > By the way, are we sure it is a good idea for the project to enforce these > rules about backward compatibility? > It seems to me that the development in OFBiz is becoming more difficult every > day and this is self evident from this small improvement that has caused a > rather long thread. > We are worried about causing harm to an hypothetical group of end users that, > we suppose, don't follow the dev lists, don't have any internal IT team that > can help them in the migration, don't have a budget for the upgrade, don't > understand about the risks of upgrading a production ERP instance and just > want to do this by blindly pressing a button. > We are sacrificing the very limited time of our brave committers against this > "myth". In my opinion we just went too far, the risk is that we go into the > mud and slow down because this plan is not compatible with the resources of > our community. There is also the risk that we are trying to fix a problem > that is not there: chances are that the silent end users have very good > budgets, very skilled IT teams that have greatly customized their OFBiz and > simple just want to take care of the critical system upgrade on their own. > So I would like to propose a change in our 'policies' to switch from > "backward compatibility" to "backward awareness" based on the following > principles: > 1) committers are encouraged to improve existing code, clean it up, improve > data model etc... even if the changes could cause some problems during > upgrade; OFBiz has to grow efficiently in the best way possible considering > the limited group of contributors > 2) however, since we know that there are companies that are willing to stay > up to date with the OFBiz growth but don't want to invest resources in the > upgrade process or staying in synch with the community, then we will do our > best to simplify the upgrade path; this means that, if time permits, > committers are encouraged to apply the deprecation patterns (for bigger and > more critical changes), or at least write some notes to warn people about the > change occurred that could impact an upgrade etc... > 3) we should also send the message out (from our site, mailing lists etc) to > the silent end users that, if they are in the process of upgrading from an > older release they should at least mention this in the user list: in this way > the community will have a chance to provide suggestions, warn about potential > issues, etc and most of all this will help the community of end users to test > together and cooperate on upgrade scripts > What do you think? > Jacopo -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
