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 >>>> >>>> >>>> >>> >
