The continual updates and addition of new stuff most certainly has been a bane of mine. So I am comfortable putting in the energy to work with ver 4.0 release. Have a lot less to keep track of for changes. Mostly bug fixes.
Since it is running in production I have a pretty good stress test. so far we have been able to avoid any major meltdowns. Jonathon -- Improov sent the following on 11/13/2007 1:00 AM: > That's a good "shotgun" method, if I understand you right. > > First, you kept your customizations separate. That's great! OFBiz > framework has many mechanisms for us to "extend" many things > (controller.xml, services, entities, etc), without having to duplicate > original codes nor to change original codes (much). > > Next, you dump in the latest changes from official OFBiz SVN, and hope > that there will be minimal conflicts. Your step above (separate > customizations) makes this hope feasible or usable. > > Still, there will be conflicts every now and then. That's where human > intervention comes in. > > Then, there's the question of blindly dumping in risky updates into a > production OFBiz implementation. Production implementations cannot > tolerate even a single hour of conflict. So, even if we do take a mere > hour to resolve all conflicts, that's still not acceptable in production > environment. Several months back, I suggested dumping risky updates into > a "trial branch", stabilizing it over a matter of days, and then merging > it back into production branch. > > All in all, it may sound complex, but practice makes it really > intuitive. Months back, I think I tried to use the analogy of > "save-points" or snapshots. Imagine being able to go back to any > save-point in your life! That would make prototyping cheaper, and make > us more agile to take risky forays into the near unknown. > > Finally, results may be better lessons than theory. You can practice > maintaining forks of several open source projects at once! It's often > necessary to correct open source projects for production use, especially > for really beta ones or for barely active ones. If you can do that, the > entire open source hypermart is open to you. It's like a huge hobby shop > where you get free materials to build your remote-controlled model/toy > planes or vehicles! > > Did I understand you right? By the way, keeping your codes in a separate > folder (OFBiz component?) still won't insulate it from new ECAs in > official OFBiz sections. I believe you asked about gotchas for ECAs? > Your codes may be minding its own business, never changing, but then > gets tripped up by a new ECA introduced into a recent OFBiz update. > > It may not always be possible to totally insulate your "separate > application folder" from OFBiz changes. If it were totally separated, > you would be reusing almost zero OFBiz ERP-related stuff. Merging is > still a necessary exercise, unless the official OFBiz branch takes care > to maintain backward-compatibility. > > The release branch 4.0 does (or should) take care to maintain > backward-compatibility. > > Jonathon > > BJ Freeman wrote: >> I am a simple person >> I find that keeping my code in a separate application folder lets me >> dump the newest version in and not worry about overwriting my code. >> and you make the human part of the individual evaluation as simple. >> from my experience of 25 years of programming I have not found anyway to >> have that happen. >> >> but for some this may be the way to go. >> >> >> >> Jonathon -- Improov sent the following on 11/12/2007 8:03 PM: >>> Yes, the "vendor branch" is a clean copy. You're right. >>> >>> The point is to be able to bring in "official updates" into your >>> customized branch in a systematic fashion. And that is to be able to >>> identify *individual* official updates in as unit a granularity as >>> possible. Some change sets can be huge with many codes being >>> interlinked, but they will almost always contain independent sub change >>> sets. Being able to systematically evaluate and bring in individual >>> independent sub change sets is crucial to successful updates to your >>> customized branch. >>> >>> And how do we get a good clean view of *individual* sub change sets? By >>> comparing one "clean" (untouched by ourselves) official revision with >>> another "clean" official revision. Maintaining a clean copy that is the >>> "vendor branch" is a must, unless you know some other version-control >>> strategy I never learned in my years with CVS/SVN (let me know!). >>> >>> It's not really that complex to merge in official updates into your >>> customized branch, although you do need to do manual (human) evaluation >>> of each independent sub change set. I do have some scripts to help cut >>> down that manual evaluation task. >>> >>> Maybe we could write an eBook on "Keeping Up With Official OFBiz Updates >>> -- Version Control Strategies"? Will that be useful to the OFBiz >>> community. >>> >>> Jonathon >>> >>> Vince M. Clark wrote: >>>> I was thinking about it the other way around. If a company or >>>> individual developer wanted to maintain their own repository and >>>> occasionally sync up with an official OfBiz branch or trunk. And they >>>> wanted to maintain a copy of the whole stack, not just an individual >>>> component. It is not always realistic to keep customizations separate. >>>> The "vendor branch" would be a clean copy of OfBiz branch or trunk in >>>> your local repository with which you could occasionally merge. This >>>> chapter in the svn book is a bit complex so maybe I misread it. >>>> Vince Clark Global Era The Freedom of Open Source [EMAIL PROTECTED] >>>> (303) 493-6723 >>>> ----- Original Message ----- From: "BJ Freeman" <[EMAIL PROTECTED]> >>>> To: [email protected] Sent: Monday, November 12, 2007 7:48:01 PM >>>> (GMT-0700) America/Denver Subject: Re: Best practice to merge your >>>> custom OFBiz with official weekly build >>>> There was some discussion before becoming a Apache incubator project >>>> about contributions (/vendor) that is similar to the svnbook, if I >>>> understand it correctly. it did not meet with much acceptance. Not >>>> sure with current man power levels it is something ofbiz wants to take >>>> on. also if you going to do a application, like I did, before we had >>>> the branch, it is almost impossible to get any development done if the >>>> trunk is continually changing and I have figure out if it is a bug >>>> created by my coding or from some commit from the trunk. >>>> >>>> >>>> >>>> >>>> Vince M. Clark sent the following on 11/12/2007 5:23 PM: >>>>> There is a chapter in the svn book about vendor branch management. >>>>> http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html#svn.advanced.vendorbr.general >>>>> >>>>> >>>>> Probably very useful if you can afford the overhead. >>>>> Vince Clark Global Era The Freedom of Open Source >>>>> [EMAIL PROTECTED] (303) 493-6723 >>>>> ----- Original Message ----- From: "BJ Freeman" <[EMAIL PROTECTED]> >>>>> To: [email protected] Sent: Monday, November 12, 2007 5:44:09 PM >>>>> (GMT-0700) America/Denver Subject: Re: Best practice to merge your >>>>> custom OFBiz with official weekly build >>>>> I created a separate folder and put my changes there. if it was a >>>>> service then I change the name of the service and put in my folder. >>>>> As a note, unless you want to spend time debugging the new >>>>> submissions, and you don't need the latests and greatest, I suggest >>>>> you use the branch. >>>>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started >>>>> >>>>> >>>>> Vedam B sent the following on 11/12/2007 4:14 PM: >>>>>> Hi, >>>>>> I wanted to customize the OFBiz version. Also, I wanted to get the >>>>>> latest updates from the official weekly build and merge with my >>>>>> custom OFBiz. Any one tried this, what are the problems faced? >>>>>> What are the best practices to achieve this? >>>>>> Regards Vedam >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: >>>> 269.15.30/1127 - Release Date: 11/12/2007 9:19 PM >>> >>> >>> >> >> > > > >
