This page might be helpful, and answers the more general question behind the question:
http://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started -David On Dec 7, 2009, at 11:05 AM, Ruth Hoffman wrote: > Hi Anil: > I feel like I'm spitting in the wind here...Please, let's just start this > conversation over again. Under the following circumstances, which version or > release of OFBiz should I use? > > I'm a new user and I want to customize my OFBiz instance for a new ERP > deployment. > > TIA > Ruth > Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz" > > > > > Anil Patel wrote: >> Ruth, >> Why don't you consider using one of the release branches? >> >> Thanks and Regards >> Anil Patel >> HotWax Media Inc >> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >> >> On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote: >> >> >>> Hi Scott: >>> Then stop the committing and do some reviewing. There is more to software >>> development than committing code to a repository. >>> >> This is interesting perspective. Trunk is expected to remain active. New >> development must continue. For the people who needs more stable version we >> do have release branch. >> >> >> >>> Regards, >>> Ruth >>> >>> Scott Gray wrote: >>> >>>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote: >>>> >>>> >>>>> Thank you Jacques for addressing this as this situation worries me >>>>> too. Although I think the power of the Ofbiz community can handle it >>>>> :-) >>>>> >>>>> My suggestions would be: >>>>> - Assign volunteers and a lead to each of the components. They can >>>>> watch issues of their components and should can be consulted if >>>>> anybody wants to make changes in their neighbourhood. >>>>> >>>> We already have these volunteers, they're called people who review commits >>>> and I could probably count them on one hand. >>>> Everything you've suggested requires more resources than this community >>>> can provide. >>>> >>>> >>>>> - Work bottom up: start with the framework, then the core modules >>>>> (party, product, accounting, workeffort, manufactureing, order) and >>>>> finally the specialpurpose modules (I personally consider humanres and >>>>> marketing to be specialpurpose) >>>>> - Communicate changes to dependent components so they can sanitize >>>>> their components >>>>> - Don't allow code without tests >>>>> - Use branching for work in progress to maintain a stable trunk (I >>>>> prefer Git over SVN but that's another topic...) >>>>> >>>>> I'm a big fan of branching, this explains why: >>>>> - Code each task (or related set of tasks) in its own branch, then you >>>>> will have the flexibility of when you would like to merge these tasks >>>>> and perform a release. >>>>> - QA should be done on each branch before it is merged to the trunk. >>>>> - By doing QA on each individual branch, you will know exactly what >>>>> caused the bug easier. >>>>> - This solution scales to any number of developers. >>>>> - This method works since branching is an almost instant operation in SVN. >>>>> - Tag each release that you perform. >>>>> - You can develop features that you don't plan to release for a while >>>>> and decide exactly when to merge them. >>>>> - For all work you do, you can have the benefit of committing your >>>>> code. If you work out of the trunk only, you will probably keep your >>>>> code uncommitted a lot, and hence unprotected and without automatic >>>>> history. >>>>> If you try to do the opposite and do all your development in the trunk >>>>> you'll be plagged by: >>>>> - Constant build problems for daily builds >>>>> - Productivity loss when a a developer commits a problem for all other >>>>> people on the project >>>>> - Longer release cycles, because you need to finally get a stable version >>>>> - Less stable releases >>>>> >>>>> Best, >>>>> >>>>> Jeroen van der Wal >>>>> >>>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux >>>>> <jacques.le.r...@les7arts.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'd like to express a feeling I have. Actually it's not only my own >>>>>> feeling but also something some users have expressed recently. >>>>>> >>>>>> I'm quite happy to see that these last times a lot of effort have been >>>>>> made in order to fix OFBiz (yes to fix OFBiz!) >>>>>> It's really great to see new features in OFBiz. But I really wonder if >>>>>> we should not slow down the pace in integrating new features for a short >>>>>> period of time and should not make and even greatest effort to have a >>>>>> more stable OFBiz. >>>>>> >>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the >>>>>> community to have a look at them and to fix the most important ones (109 >>>>>> are considered as at least important) ? >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> >>>>>> >> >> >>
