I like the information that the struts project has on their release plan page. Maybe something similar? http://struts.apache.org/2.x/docs/release-plan-201.html
Mike BJ Freeman wrote: > David, > what needs to be said on the release Plan, for it to be implemented? > > BJ Freeman sent the following on 4/17/2007 9:58 AM: >> I have read the release plan, however it has been there for a while and >> we can't seem to get to the next step of implementing. >> I am guessing everyone is saying lets get a move on. >> Action >> >> David E. Jones sent the following on 4/17/2007 8:55 AM: >>> This is a very relevant topic, but it might be helpful to in terms of >>> the existing Release Plan: >>> >>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan >>> >>> I don't see people referring to this much or talking in terms of "this >>> is the plan, but maybe we should do it X way because of Y". Is that >>> because the Release Plan is just total crap, or maybe it's too long and >>> not worth reading? >>> >>> But yeah, these things are addressed in the Release Plan. >>> >>> -David >>> >>> >>> On Apr 17, 2007, at 10:05 AM, Jonathon -- Improov wrote: >>> >>>> What about simply forking a release branch now, and then we work on >>>> stabilizing and debugging THAT branch? >>>> >>>> As and when new fixes go into the trunk, we can merge those fixes into >>>> the branch. Ideally, the release branch will not take in new features >>>> from the trunk, but only fixes to bring the branch towards stability >>>> for final release. I'd recommend using Release Candidates. >>>> >>>> I'd be the first one to offer to test the release branch in the effort >>>> to bring it to release status. If there _is_ a release branch, I'll be >>>> basing my work on that branch rather than the trunk, anyway. >>>> >>>> If no one else is familiar with this branching strategy, I may be >>>> willing to take on the admin work for this. Just let me know when my >>>> deadlines and what my deliverables will be. >>>> >>>> Jonathon >>>> >>>> Si Chen wrote: >>>>> The SVN right now is in reasonably good shape in my opinion -- it's >>>>> been more stable in the past, but there's also been a lot of times >>>>> when it's a lot less stable. I think we need to get the framework to >>>>> a stable point and resolve any critical applications bugs, and then >>>>> it should be a pretty good release. >>>>> Having said that, is it better to create a release branch now, or >>>>> wait a little bit? This would depend on everybody's development >>>>> plans. I notice David and Andy are doing a lot of things in the >>>>> framework and base methods and that there have been some bugs that >>>>> are being fixed. Could the next few days, week, or two weeks be >>>>> spent primarily addressing these issues without a lot of new features >>>>> being committed? If so, then it'd be better to wait until then. >>>>> Otherwise, let's just make the release branch before a whole bunch of >>>>> new but not necessarily critical features or refactorings arrive. >>>>> Shi Yusen wrote: >>>>>> +1 for creating a release branch. >>>>>> >>>>>> >>>>>>> Also, without responses the branch will basically just include >>>>>>> whatever it includes. >>>>>>> >>>>>> As an training course, I have arranged a man to test current HEAD in >>>>>> different enviroments. >>>>>> >>>>>> I think the release branch can be created now. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Shi Yusen/Beijing Langhua Ltd. >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------ >>>>> No virus found in this incoming message. >>>>> Checked by AVG Free Edition. >>>>> Version: 7.5.446 / Virus Database: 269.5.0/763 - Release Date: >>>>> 4/16/2007 5:53 PM >> >> -- Millcreek Systems, Inc. P.O. Box 9835 Salt Lake City, Utah 84109 Phone: 801.649.4903 Skype: millcreeksys (http://millcreeksys.com/skype/)
