Hi BJ, If we customize an application by configuration, upgrades are easier. If we customize by replacing the codes, upgrades will not be possible. This means functions / features in OFBiz should be able to turn on / off.
Regards, James BJ Freeman wrote: > > I disagree. every complicated process is made up of simple processes. > the level you approach it, is what makes it complicated. > An I believe the process can be modeled and implemented. > > just as the tests are now, as limited as they are. > > what it takes is a commitment by each one that changes the code base to > put their smarts in the direction of what does it take to get from here > to there as far as migration. > > one way for instance is to use Diffs or even the patch itself as a basis > for driving the migration. > > then is it a matter of tools to use the diffs and patches to run a check > on customization. > > I do maintain my own SVN, I would not be this far if I did not. > however it does not help to compare code that outside that of the ofbiz > svn(component that are customized but not part of the code base of ofbiz) > > The bottom line, for a business, is overhead to maintain it hard cash. > > > > > Jonatan Soto sent the following on 9/22/2010 5:00 PM: >> What I see here is that it is not as easy to create an upgrade system for >> this kind of project. Perhaps the nature of it, it's a good reason. >> Remember >> that Ofbiz is an ERP system and tries to cover as much as it can >> different >> businesses, so IMO it's not like a proprietary product or another kind of >> open source project where it is not a common practice to change the trunk >> code by everyone and also allows to easily install plugins, mods, >> extensions, etc. >> >> IMO, I can say that one good chance to achieve this is to separate the >> framework from the apps, already discussed in a lot of posts and I think >> it >> is strongly accepted by the community. This will get the ability to >> extract >> an important piece of code which I think is not regularly altered, at >> least >> in my case, I've modified some apps but never the framework. >>> From my point of view, the hot-deploy works fine and it's fairly enough >>> for >> a lot of customization purposes and maintain the trunk code untouched. >> But >> it seems to me that sometimes is not enough mostly when an adaptation of >> an >> existing app, concretely i18n enters the scene. For example I found to be >> very complicated to move the entire Accounting module, IMO the one that >> requires more i18n, since it is related with a lot of modules. In this >> case >> I have had to customize in-place. I have some ideas about that, but I >> prefer >> to discuss this in a proper post. >> >> BJ, I believe that your problem is related with the number of >> installations >> do you have/maintain so a little solution may be (if you aren't doing >> yet) >> the vendor drop technique ( >> http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html). But I >> suppose it's only valid if you decided to use the trunk version from the >> beginning and kept up to date so often... >> >> On Thu, Sep 23, 2010 at 12:44 AM, Jacques Le Roux< >> jacques.le.r...@les7arts.com> wrote: >> >>> From: "Adam Heath"<doo...@brainfood.com> >>> >>> On 09/22/2010 03:33 PM, BJ Freeman wrote: >>>> >>>>> Am it to gather by this that you can do a direct SVN update and all >>>>> your >>>>> customization continue to work? >>>>> say from 9.04 to 10.04 >>>>> >>>> >>>> Ofbiz has never supported upgrades. I agree with BJ here. >>>> >>>> Database tables can change. Not all changes are automatic. Such >>>> changes >>>> are not listed in a simple place(in the source). >>>> >>>> Values in tables can change. No upgrade conversions are >>>> provided(again, >>>> in a simple place). >>>> >>> >>> Is this useless? >>> >>> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration >>> >>> Jacques >>> >>> >>> To solve this, requires running older ofbiz on older database, doing a >>>> test upgrade to each and every new version, and then seeing what is >>>> different. This is a *very* hard problem, not easy to automate, and >>>> takes >>>> smart people lots of time. This is not something you can just force on >>>> the >>>> community. No one has sat down to do this very busy, hard work, so it >>>> hasn't yet been done. >>>> >>>> If you run trunk, then it is up to you to solve any per-version upgrade >>>> problems. >>>> >>>> However, official releases should really have appropriate, detailed, >>>> upgrade instructions. >>>> >>>> >>> >> >> > > > -- View this message in context: http://ofbiz.135035.n4.nabble.com/Design-improvements-tp2550130p2551300.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
