2009/1/30 Rafael Schloming <[email protected]>:
> Martin Ritchie wrote:
>>
>> 2009/1/30 Marnie McCormack <[email protected]>:
>>>
>>> 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
>>> <[email protected]>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:[email protected]
>>>>
>>>>
>>
>> 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?
>
> Actually the 0-8/9 ruby client is still there and should still work. I think
> the bigger issue is that other than JMS, the client APIs are different for
> 0-8/9 and 0-10, so it's still possible to get confused and think that there
> is no interop even though there is.
>
> As an aside, speaking of JMS, we should probably put JMS somewhere near the
> Java client entries on that page in order to make it clear that our Java
> client is actually a JMS impl.
>
>> 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.
>
> What do you mean by release individual packages for all components?

I thought we agreed at the end of last year that we were going to move
to release by components rather than language. e.g.
Brokers
qpid-c++-broker
qpid-java-broker

Clients
qpid-c++-client
qpid-dotnet-client
qpid-java-client
qpid-ruby-client
qpid-python-client

Management
qpid-management-cli
qpid-management-eclipse
qpid-management-qman
...

That way if a user only wants to have the C++ broker and Java client
they only need download those components. It also makes it way easier
to say. Hey new version of component X now available.That said, We
should still have a full release of version X.0.0 with all components
but then allow each component to do point releases as is needed for
bug fixes, small enhancements, but fully compatible.

Martin

> --Rafael
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[email protected]
>
>



-- 
Martin Ritchie

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

Reply via email to