I suppose we are shameless optimists and hope that people will choose to collaborate with other people using the software, and perhaps even participate in the development.
Still, I agree the big download button is a bad design and I never liked it given that there are various options to download and personally I like the idea of making people make choices... ;) -David On Dec 7, 2009, at 11:28 AM, Ruth Hoffman wrote: > HI David: > If that resource is the "definitive" answer, then why does that "BIG FAT > DOWNLOAD" button/link point to a "trunk" build? Shouldn't it point to a > "release branch tag" build with a good probability of working? > Am I missing something here? > Am I not reading all this information correctly? > Why does that button point to a build using Java 1.6 when that couldn't > possibly be a build that has any history of testing behind it..you just > started using Java 1.6 after all. > > TIA > Ruth > > David E Jones wrote: >> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >> >> >>
