I know we used to have a release management document on old confluence. Its matter of locating it.
I request, Please don't draw conclusions so quickly. Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" On Feb 16, 2010, at 8:40 AM, Ruth Hoffman wrote: > It is ironic. > Ruth > > Christopher Snow wrote: >> It's kind of funny that ofbiz promotes the use of best practice in many >> areas >> (http://cwiki.apache.org/confluence/dosearchsite.action?queryString=ofbiz%20best%20practice) >> EXCEPT release management. >> >> Ruth Hoffman wrote: >>> Hi Jacopo: >>> Its nice to see this kind of thought going into a release strategy. Thanks >>> for the effort. Please see my comments inline. Note, this is just my >>> opinion based on years of working with big complex IT organizations. These >>> are the kind of "users" who ultimately would be implementing OFBiz (I >>> hope...): >>> >>> Jacopo Cappellato wrote: >>>> I know this subject has been already discussed several times in the past, >>>> but I still would like to rethink our strategy for releases in OFBiz. >>>> I am under the impression that, considering the release branch 9.04, that >>>> is our latest release branch: >>>> * there are more users than maintainers >>>> >>> This is probably true. But to get a better understanding of who is using >>> what, maybe we could look into getting download statistics? I have already >>> put in a request to the infrastructure team for this, but have not heard >>> anything back from them. Maybe a project committer has more clout and could >>> get this implemented? Without that, we are just speculating about who is >>> doing what with the code. >>>> * because of this, no real maintenance plan, test strategy etc.. has been >>>> created around it from the community of users and interested parties (in >>>> fact we were not really able to officially release it) >>>> * a lot of new users start eveluating OFBiz from that instead of the trunk >>>> * it is rather old, several new features are missing and also code >>>> improvements (that could fix bugs etc) >>>> >>> I thought all the bug fixes were retrofitted to the release? Is this not >>> true? >>>> * because of this, it tends to be less stable than the trunk >>>> >>> How could the release be less stable than the trunk if bug fixes are >>> applied to the release and the trunk? >>>> The main cons of this situations are the following: >>>> 1) not real interest in maintaining a release branch means that we will >>>> not be able to spend time on it and officially release it: the OFBiz >>>> community will miss the advantage of using the marketing channel >>>> represented by a new release >>>> 2) new users will get the wrong impression that the project is slowing >>>> improving if they just get the releases >>>> >>> Project committers should consider this behavior pattern: Most people >>> evaluating code will not want the latest release. They will patiently wait >>> until someone else has taken on the risk (and reward) of debugging it. Do >>> not think that just because the project releases a new release of OFBiz, >>> that everyone will stampede to get it. Far from it. Now if we had download >>> statistics we could verify my claim, but I'd be willing to bet real money, >>> that the only people who will jump to download this new release will be >>> project committers. >>>> 3) it is much easier for a user to stay up to date with the trunk rather >>>> than with a release: I mean that there is no guarantee that one day >>>> someone will build an upgrade plan from the old release to the new one... >>>> users of the old release may be left behind forever >>>> >>>> >>> I think you mistake "user" with "committer". What "user" is actively trying >>> to stay current with the trunk? Just some food for thought. >>>> What I suggest is based on the following assumptions: >>>> 1) community is not ready or interested in maintaining releases >>>> >>> Only the "committers" are not interested. Users out there may have a >>> different story to tell. Personally, I'd like to see releases "maintained". >>>> 2) new users prefer to start evaluating OFBiz with a release instead of >>>> the trunk >>>> 3) it is good for the project to announce new releases often >>>> >>> True. Very true. >>>> 4) because our current policies (slowly increasing number of committers, >>>> peer reviews, etc...) our trunk is (and will be) more stable than older >>>> releases >>>> >>>> >>> Again, why? I thought bug fixes are committed back to a release if >>> appropriate. Is this not the case? >>>> Here is what I suggest: >>>> A) define an official release plan that says that we officially issue a >>>> release every approx 6 months (just to give you an idea): since there is >>>> no way to define a set of features that will go in the next release, our >>>> releases will be based on dates instead of features; but of course we can >>>> discuss the exact time of a release based on what is going on 1-2 weeks >>>> before the release date >>>> >>> Don't release every 6 months. That's crazy. Once a year is sufficient. Put >>> in place a real release plan including features, fixes and upgrade >>> instructions in advance and then work towards making OFBiz something more >>> than just a developer's playground. Make it "stable" by setting out in >>> advance what "stable" means. And then work towards making each release meet >>> the "stability" requirements. Just releasing something every 6 months or a >>> year does not a "stable" release make. >>>> B) there is no guarantee that patches will be backported to releases, that >>>> upgrade scripts will be created from release to release >>>> >>>> >>> If so, then what is the point of even having releases? Just have nightly >>> trunk builds and everyone is happy. >>>> It is true that the ASF policies ask that a release, that represents the >>>> code that is distributed by the ASF to the larger audience of users, is a >>>> "stable" deliverable; but if we continue with the current approach, even >>>> if it is intended to get a stable and maintained release, what we are >>>> really doing is distributing the code in the trunk (this is what we >>>> suggest our users to use instead of the release), not the "stable" release. >>>> >>>> >>> IMHO, one of the true benefits of going with the ASF is the structure and >>> stability they enforce on umbrella projects. Why not use these >>> "restrictions" to the project's advantage instead of trying to circumvent >>> them. I think I'm agreeing with you in that maybe "we" should start >>> pointing users to releases instead of trunk code. Just a thought. >>> >>> Ruth >>>> What do you think? >>>> >>>> Jacopo >>>> >>>> >>>> >>>> >>>> >> >>
