De : "BJ Freeman" <[EMAIL PROTECTED]> > 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.
Yes, releases should definitively help to increase community and especially business interests ! Jacques > 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: user@ofbiz.apache.org 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: user@ofbiz.apache.org 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 > >>> > >>> > >>> > >> > >> > > > > > > > > >
