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
