qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: Changing the release numbering scheme (was Re: [VOTE] Version Numbers)
Date Tue, 10 Feb 2009 22:25:10 GMT
Steve Huston wrote:
>> Aidan Skinner wrote:
>>> On Tue, Feb 10, 2009 at 1:24 PM, Carl Trieloff 
>> <cctrieloff@redhat.com> wrote:
>>>> If we could agree to get 0-10 into the Java Broker in a 
>> timely fashion and
>>>> then change then
>>>> go to 1.0, I am fine with that. However, the 'M' is a pain 
>> and if we don't
>>>> reach that point for
>>>> the next release I would prefer to go to 0.5 for the next
> release.
>>> I don't think that adding 0-10 support to the Java broker 
>> is the only
>>> step necessary before we declare ourselves 1.0. I'm not sure that
>>> there's a consensus around what would be Qpid 1.0 just now.
>> What else do you feel is necessary?
> I think the API consistency/ease-of-use is more of an issue than the
> protocol compatibility.
>> For me it's all about interop across 
>> the different languages, and the biggest part of that is 0-10 
>> support in the Java broker.
> Ok.
>> I'd also like to see some progress on protocol neutral 
>> APIs in other languages, but I actually think thats an area 
>> where we can whip things into shape with relatively little work.
> I think that protocol-neutral API is going to end up a larger effort
> than protocol implementation/interop. It ripples very far. It's also
> what most newcomers will be affected most by as they start to look at
> how to use Qpid for projects.

I certainly agree consistency and ease-of-use need to be a focus, but 
for me the minimum bar for X.0 is that we can update the protocol 
version without breaking deployed apps. The current APIs are mostly 
there, but there are a few spots where they are a bit too close to the 
wire and should have something slightly higher level in place. I think 
once we achieve this level then consistency and ease-of-use can be done 
with backwards compatible changes.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message