2009/1/30 Marnie McCormack <marnie.mccorm...@googlemail.com>: > I think our download page should be just that ! > > There's a release compatibility matrix which shows which bits currently work > together - so I don't think the download page is the place to try and convey > this info. The python client (as the Java client) appears to be the same > package on both tables. > > The current download page needs changed - it could be taken to imply to a > user that the java client and broker do not interop. Some info about interop > could be added, to explain that the C++ broker is not backwards compatible. > > Marnie > > Some of this discussion is really about interop and backwards compatibility. > D > On Thu, Jan 29, 2009 at 10:29 PM, Jonathan Robie > <jonathan.ro...@redhat.com>wrote: > >> Carl Trieloff wrote: >> >>> >>> >>>> I'd prefer not to be separating components from the same release out by >>>> AMQP >>>> version as I think it sends the wrong signal and is not how we actually >>>> make >>>> releases i.e. we released M4 not AMQP 0-10. >>>> >>>> >>> >>> that was me, to try make it really easy to know what works with what, >>> based on some questions on >>> the user list. Is it not clear that it is not all part of M4? ideas to >>> make it better... >>> >> >> I liked the way we had it, but I'm happy with any approach that makes it >> very clear which pieces are compatible. >> >> I really don't want people to download incompatible bits, shrug, and move >> on to some other implementation. >> >> Jonathan >> >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:dev-subscr...@qpid.apache.org >> >> >
But are the C++ client and the Ruby client not the only two that don't work with the Java Broker? Java, Python and .Net all work with 0-8/9 and 0-10? As there are more clients that are compatible than are not I'd say we should put a caveat on the two incompatible clients, if the compatibility matrix is not enough. Splitting the download page by AMQP version suggests that the Java broker is not as functional because it doesn't support the latest protocol version when in reality only two clients don't work. If we hadn't deleted the 0-9 C++ client then we would still have a C++ client for the Java Broker and so compatibility issues wouldn't need to be mentioned. Was the old Ruby client that supported 0-8/9 discarded when the 0-10 work was done, I'd say we should bring it back in a similar way to the .net unless we plan on putting multi-protocol support in to the current Ruby client. Was that not the only AMQP 0-8/9 Ruby client? It is a matter of presentation to users, the fact that the 0-10 has twice as many items as the 0-8/9 suggests that it is in some way better, when the 0-8/9 items are duplicates from the 0-10 section. When we get to M5 and release individual packages for all components (not just .Net) then I think things will be easier but for that to occur I think the download page should be grouped Brokers and Clients. I think this will work just now and be clearer to the end user. Just my two cents on a Friday morning. Martin -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
