Anyway, according to the road-map we should try to have those implemented: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310500&fixfor=12313602
-Bruno 2009/2/2 David E Jones <david.jo...@hotwaxmedia.com> > > Yes. It will be the same as the release4.0 branch, and in general follow > the pattern/process described here: > > http://docs.ofbiz.org/display/OFBADMIN/Release+Plan > > -David > > > > On Feb 2, 2009, at 9:52 AM, Vince M. Clark wrote: > > Please clarify the process. Are we continuing to work in trunk and then >> take a snapshot in March, calling that Release Branch 9.3? >> >> ----- Original Message ----- >> From: "David E Jones" <david.jo...@hotwaxmedia.com> >> To: dev@ofbiz.apache.org >> Cc: "Rajib Khan" <ra...@arlnet.com>, "Guy Gershoni" <g...@conchus.com>, >> "Peter Stone" <peter_st...@arl.com.au> >> Sent: Tuesday, January 20, 2009 1:25:17 AM (GMT-0700) America/Denver >> Subject: Re: New Release Branch (was: locale error in simple method) >> >> >> Unless I'm misunderstanding I think the answers to your questions are >> earlier in this thread. As implied by the name, the planned release >> branch date would be March 2009 (hence the 9.3, in the Ubuntu style). >> >> As for a "stable" branch with errors worked out, the comments about my >> expectations of at least three months and our experience with >> release4.0 of 6-9 months are the best answer available (AFAIK anyway). >> >> As for "safe" extensions to OFBiz... changing classes is a no-no and >> can usually be avoided by some sort of contribution with either the >> literal change you need, or something that makes the class more >> flexible so that you can intercept elsewhere with the change you need. >> In general, class extension is NOT a very good form of creating >> extended functionality that is easy to maintain, no matter what OO >> folks say. You can do a lot with the cart by creating custom request >> events instead of using the default ones, and if the ShoppingCart and >> related classes were a bit cleaner and more flexible (which has been >> discussed a number of times, even recently) then even more could be >> done. >> >> -David >> >> >> On Jan 19, 2009, at 5:59 PM, Luke Prentice wrote: >> >> hi guys, >>> >>> my colleagues (rajib khan and guy gershoni) and have been working >>> with ofbiz >>> for over 3 years now. we're currently going through the process of >>> "upgrading" to the latest trunk of ofbiz. we've done this >>> periodically for a >>> few months and tried really hard to keep our own customisations >>> abstracted >>> out (so merges are less painful). >>> >>> i've been following this discussion with interest. because of the >>> pain of >>> merging in changes from a not-totally-stable trunk (i know that it's >>> not >>> stable -- cos it's a development trunk!) we need to decide when to >>> "cut our >>> losses" and move away from the development trunk. some of the recent >>> changes >>> have been radical enough to slow down our development significantly. >>> >>> so... we'd like to stay "connected" to the development community and >>> contribute back changes where that's useful (eg >>> https://issues.apache.org/jira/browse/OFBIZ-1906). plus we can of >>> course >>> benefit from fixes in the trunk. however, on reflection, the >>> destabilisation >>> that results from merging is too great a burden for us to keep >>> doing. (eg, >>> commit 712932 to ShoppingCart.java was a deep problem for us because >>> we're >>> extending a number of classes in this file). >>> >>> [aside: a potential discussion is whether or how can ofbiz users >>> customise >>> classes? is it bad practice? in our case we have modified the >>> shopping cart >>> because we want the OrderItem to be extended too.] >>> >>> hence my interest in this topic. specifically because our team would >>> like to >>> "lock on" to a stable release branch. we're way ahead of release >>> branch4.0 >>> and have noticed release9.3 appeared recently. >>> >>> given the list of "must do" and "would like to get done" *before* >>> release9.3 >>> is bedded down, what is a reasonable time frame for this to happen? >>> >>> short version: *when will release branch 9.3 be committed as stable?* >>> >>> the answer to that will determine whether we remain connected to the >>> trunk >>> and seek to commit/merge changes and "play our part" in the community. >>> >>> many thanks, >>> >>> luke. >>> >>> On Sun, Jan 18, 2009 at 6:16 PM, David E Jones >>> <david.jo...@hotwaxmedia.com>wrote: >>> >>> >>>> Sounds like you're leaning towards using the trunk... ;) >>>> >>>> -David >>>> >>>> >>>> >>>> On Jan 17, 2009, at 11:58 PM, Brett Palmer wrote: >>>> >>>> Maybe every 3 months was too optimistic. I just seems like a year >>>> is a >>>> >>>>> long >>>>> time to wait for another release. Especially if you are working >>>>> with one >>>>> of >>>>> the new ofbiz applications like workeffort and you want new >>>>> features as >>>>> they >>>>> become available.. >>>>> >>>>> >>>>> Brett >>>>> >>>>> On Fri, Jan 16, 2009 at 10:56 AM, David E Jones < >>>>> david.jo...@hotwaxmedia.com >>>>> >>>>> wrote: >>>>>> >>>>>> >>>>> >>>>> My reply to another message seems to fit this exactly: >>>>>> >>>>>> ============================================ >>>>>> I'll acknowledge that more than one release per year could >>>>>> happen, but >>>>>> I'd >>>>>> be really surprised to see it happen. When a release branch is >>>>>> done it >>>>>> seems >>>>>> to take many months to back-port enough bug fixes from the trunk >>>>>> and get >>>>>> fixes in from other sources to actually make it fairly solid and >>>>>> functional. >>>>>> >>>>>> We also have the issue of update paths and scripts or whatever. >>>>>> If we >>>>>> have >>>>>> too many releases it causes a lot more confusion for prospective >>>>>> users >>>>>> about >>>>>> which release to use, and also causes more effort to maintain >>>>>> more update >>>>>> paths between releases. If we only release every 1-2 years then >>>>>> it is >>>>>> generally pretty clear which one to use. >>>>>> >>>>>> Actually, I've spelled a lot of this out a long time ago here and >>>>>> as far >>>>>> as >>>>>> general concepts and issues go I don't think much has changed: >>>>>> >>>>>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan >>>>>> ============================================ >>>>>> >>>>>> To sum up: we could certainly try it (I'm up for trying >>>>>> anything), but I >>>>>> think with the lack of resources that a single release branch was >>>>>> able to >>>>>> rally it would be even more distracting and dispersing of >>>>>> resources to >>>>>> have >>>>>> multiple release branches close together. My guess was 3 months >>>>>> to get >>>>>> bugs >>>>>> worked out of a release branch, and I think it really took more >>>>>> like 6-9 >>>>>> months for release4.0. If we do releases closer together I don't >>>>>> think >>>>>> they >>>>>> will EVER get cleaned up with the bugs worked out. >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>>> >>>>>> On Jan 16, 2009, at 5:21 AM, Hans Bakker wrote: >>>>>> >>>>>> I think this is good proposal. >>>>>> >>>>>> it should be automatically scheduled.... and update script is a >>>>>>> good >>>>>>> idea... >>>>>>> >>>>>>> so please (re)read this proposal. >>>>>>> >>>>>>> Hans >>>>>>> >>>>>>> ps. the attachment not really get trough? >>>>>>> >>>>>>> On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote: >>>>>>> >>>>>>> Here is another proposal for release branches. Rather than >>>>>>> doing a >>>>>>> >>>>>>>> release branch every 1 - 2 years how about doing it by calendar >>>>>>>> and >>>>>>>> releasing a new branch more frequently (e.g. every 3 months). >>>>>>>> The >>>>>>>> objective would be to stay as close to the trunk as possible >>>>>>>> while >>>>>>>> still providing stability for production releases. >>>>>>>> >>>>>>>> All appropriate fixes for the release branch would go back into >>>>>>>> the >>>>>>>> trunk. Then after 3 months we would create another release >>>>>>>> branch and >>>>>>>> start the process all over again. The community could also >>>>>>>> provide >>>>>>>> update scripts to help production deployments move from one >>>>>>>> release >>>>>>>> branch to another. This is currently a pain now and is one of >>>>>>>> the >>>>>>>> reason I think people don't update their production deployments. >>>>>>>> >>>>>>>> I'm attaching a graphic that shows how this proposal would work. >>>>>>>> >>>>>>>> I'll also put in another plug for community driven test cases. >>>>>>>> The >>>>>>>> test cases would be used to determine when the release branch was >>>>>>>> stable enough for a recommended general release. >>>>>>>> >>>>>>>> >>>>>>>> Brett >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jan 15, 2009 at 6:07 PM, David E Jones >>>>>>>> <david.jo...@hotwaxmedia.com> wrote: >>>>>>>> >>>>>>>> I just setup your jira permissions Bruno (sorry for forgetting >>>>>>>> that earlier) and you should be able to do this now. >>>>>>>> >>>>>>>> How we want to do this is a good question. I suppose defining >>>>>>>> a release target is the way to go, and we can use that for bug >>>>>>>> reporting after the branch is created as well. >>>>>>>> >>>>>>>> As for the version name of the release we should talk about >>>>>>>> it. Thinking about it now we have discussed doing a release >>>>>>>> branch once per year, and perhaps once every 2 years. Perhaps >>>>>>>> we should version the release with the year? I've never liked >>>>>>>> that approach a whole lot, because in many cases it is less >>>>>>>> meaningful that a major/minor version number, but for OFBiz >>>>>>>> the release branches are time based so perhaps a year makes >>>>>>>> sense. >>>>>>>> >>>>>>>> If we do that this next release could simply be "release2009", >>>>>>>> or if we want to be more specific and perhaps use the Ubuntu >>>>>>>> model (and assuming we're planning for a release in March) we >>>>>>>> could use something like "release9.3". I think I like the >>>>>>>> simple release2009 better... >>>>>>>> >>>>>>>> Any other opinions? >>>>>>>> >>>>>>>> -David >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> could you create the new version in JIRA so that we >>>>>>>> can schedule these >>>>>>>> issues on it and have them displayed in the Road Map? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -Bruno >>>>>>>> >>>>>>>> 2009/1/16 David E Jones <david.jo...@hotwaxmedia.com> >>>>>>>> >>>>>>>> >>>>>>>> On Jan 15, 2009, at 3:33 PM, Adrian Crum >>>>>>>> wrote: >>>>>>>> >>>>>>>> David E Jones wrote: >>>>>>>> >>>>>>>> What do we still have that is >>>>>>>> up in the air for refactoring, >>>>>>>> cleanups, >>>>>>>> and enhancements? I know quite >>>>>>>> a few have been worked on >>>>>>>> recently but I'm >>>>>>>> not sure of their exact >>>>>>>> status, but here are some that >>>>>>>> come to mind: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-1868 >>>>>>>> >>>>>>>> >>>>>>>> Yes, that would be a good one to get done. >>>>>>>> >>>>>>>> There may also be other framework versus apps >>>>>>>> issues that need to be >>>>>>>> resolved, actually I know there are (Bruno >>>>>>>> brought one up today in fact). >>>>>>>> >>>>>>>> -David >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive prices >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >> >
