2009/1/15 Aidan Skinner <aidan.skin...@gmail.com>: > On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <g...@redhat.com> wrote: > >>> If the features on the page for M5 are more, shall we say, aspirational - >>> let's use them as a roadmap for 2009. >> >> I'm certainly keen on understanding how our roadmap will take us to the >> point where all Qpid components interoperate with each other. If it is not >> feasible for the next release thats fine. > > I suspect the most achievable way to approach this is to refactor the > broker and improve the test coverage for M5, then add extra protocols > after that.
Let me play devil's advocate for a moment. I buy the argument that a full java multi-protocol bonanza is not achievable in M5 timeline. And I also agree that one of the key things users want is a stable product even in unforseen production circumstances, so flow to disk would seem to be an important feature to add for M5. So if we accept that M5 will be a stability release, do we want to risk destabilising other areas by performing signfiicant refactoring? Even with the best efforts for test coverage, you would have to be honest to potential users to say that there is some degree of risk in an M5 that also had significant refactoring. So with that logic I'm led to the conclusion that M5 should be a relatively focussed "stability and minor feature" release (for Java broker at least) before it embarks upon major upheaval for M6. M6 will probably really be a "point zero" release and users who demand total production stability would only look to pick up M7 or M8. And I really think we should bin this silly Mx release numbering convention:-) RG
