Click previous versions - it takes you were you have options. You don't need the options on the home page IMO.
Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Dec 7, 2009, at 3:51 PM, David E Jones wrote: > > The point is we need more than one so people can choose, and are more aware > that there is a choice. > > -David > > > On Dec 7, 2009, at 2:13 PM, Tim Ruppert wrote: > >> Most of the major projects have a big DOWNLOAD button - it's a good idea - >> and I'd be surprised if a call to action does not encourage more people to >> download. >> >> Cheers, >> Ruppert >> -- >> Tim Ruppert >> HotWax Media >> http://www.hotwaxmedia.com >> >> o:801.649.6594 >> f:801.649.6595 >> >> On Dec 7, 2009, at 12:55 PM, Jacques Le Roux wrote: >> >>> From: "David E Jones" <d...@me.com> >>>> 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... ;) >>> >>> If number of people don't like it, then it should be discussed >>> >>> Jacques >>> () ascii ribbon campaign against HTML e-mail >>> /\ www.asciiribbon.org >>> >>>> -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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
