IMO the button should direct to a (wiki?)page wich contains links to the latest 9.04 release, setup instructions and end-user documentation. -Jeroen
On Wed, Dec 9, 2009 at 7:44 PM, Ruth Hoffman <rhoff...@aesolves.com> wrote: > Hi Jeroen: > Thanks for you quick reply! > To the list and the PMC specifically: > Could we change the "BIG FAT DOWNLOAD" button to point to this > branch/release? Please? Should I enter this request as a JIRA? > > Thanks again. > > Ruth > ---------------------------------------------------- > Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz" > ruth.hoff...@myofbiz.com > Jeroen van der Wal wrote: > >> Hi Ruth, >> >> Branching is a term common to developers so I understand the confusion. >> There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking >> for the latest version of the latest release use this link: >> http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip >> Again a point proven that the community is focused towards developers. >> Keep >> asking. >> -Jeroen >> >> On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rhoff...@aesolves.com> >> wrote: >> >> >> >>> Hi Anil: >>> Thanks for your notes. Please excuse me if I seem a bit pushy here, but >>> could we please take this logic one step further? >>> >>> Which of the many download options on the http://build.ofbiz.org is the >>> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the >>> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak >>> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been >>> there >>> with that release; no need to go down that path :-) >>> >>> I don't see the word "Branch" anywhere on this page. Should I keep >>> staring >>> at the page longer? Did I miss something? >>> >>> Seriously, I want to start with a new, clean version of OFBiz and begin >>> some 9.04 updates to my books. Where should I start in your estimation? >>> >>> Regards, >>> Ruth >>> ---------------------------------------------------- >>> >>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz" >>> ruth.hoff...@myofbiz.com >>> >>> Anil Patel wrote: >>> >>> >>> >>>> Ruth, >>>> Its depends on How you plan to work. >>>> If a 1) branch has all features you need 2) you plan to only >>>> customize for business use >>>> 3) Don't plan to contribute enhancements to Ofbiz trunk. >>>> Then Use Branch >>>> Else If >>>> 1) You need features from latest trunk 2) You don't care for >>>> upcoming features >>>> 3) You don't care for contributing enhancements to Ofbiz trunk >>>> Then Create Vendor branch from current trunk revision. This is >>>> painful >>>> and not easy. Else >>>> Keep current with trunk, work with community to get it better. >>>> End If >>>> >>>> These are my personal quick notes for you. I know David has already >>>> directed you to page that has more complete answer. >>>> 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 12:05 PM, 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>> >>>> >>> >> >> >
