Jacques, Thanks for quick help. 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 11:18 AM, Jacques Le Roux wrote: > http://cwiki.apache.org/confluence/display/OFBADMIN/Release+Plan > > Thanks for the reminder Anil! > > Jacques > > From: "Anil Patel" <[email protected]> >> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >> > >
