I can understand the various views of what we need to achieve to call Qpid a more complete product. I agree with many of the goals put forward and I'm glad we're discussing them.
However, we have been on the go with releases that users have deployed into production since 2006. For me, the notion that we're less than 1.0 is somewhat nonsensical given production applications of Qpid and the robustness & reliability of the Java components (at least, other elements outside my ken). The clients/brokers have historically interop-ed and we have made some poor decisions subsequently. I'm not sure that takes us directly backwards. However, this is not an area I'm that passionate about. I guess my point is that I think we need to be careful about putting too much significance on the "version number as project description" view. We absolutely do need to have a coherent set of project goals, including inter-op, API changes, feature compability etc. Essentially the numbering of our releases will not be that significant to our users (I am never, ever asked about the number - a comprehensive test suite with published results benchmarked would be a far more compelling argument for use.) I'd find it hard to explain to users with production deployments that we're somehow a less than 1.0 product. For me, we're hanging other (important) project discussions off the wrong hook. My tuppence ... Marnie On Tue, Feb 10, 2009 at 9:56 PM, Robert Greig <[email protected]>wrote: > 2009/2/9 Aidan Skinner <[email protected]>: > > >> I think it would be good to have a discussion - hopefully leading to > >> consensus (!) - on what people think we need to have achieved to merit > >> a 1.x release. To my mind, if people agree those items and they are > >> different from what is in scope in our next release, that implies we > >> don't have the correct focus for our next release(s). > > > > I think that's a separate issue. We do need to talk about our release > > process a bit more, but that's probably best done in another thread. > > Possibly this one: http://markmail.org/message/5bxobdc23rgbmqu7 > > Well, people seem to have a view that we need to have certain features > (APIs, protocol compatibility) to be able to have an X.0 release so I > think it is directly related. > > I don't think it's related to our release process though? > > >> My own view is that Mx is a weak numbering scheme - something I have > >> always felt and I have no idea why incubator projects have to be > >> numbered (or should I say encumbered) in such a way. I am not sure > > > > They're not. I'm not sure where that idea originated, but it's never > > been a requirement for podlings to release Mx numbered artifacts. I > > think the "all podling release have to be M.x releases" fallacy is an > > instance of the monkey/hose/banana problem[1]. > > Interesting, I wonder how we ended up with such a poor numbering > scheme in the first place. Anyway, that is a historical detail now I > suppose. > > RG > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
