qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Ritchie <ritch...@apache.org>
Subject Re: version number proposal
Date Thu, 05 Feb 2009 14:49:48 GMT
2009/2/5 Rafael Schloming <rafaels@redhat.com>:
> Robert Greig wrote:
>>
>> 2009/2/3 Rafael Schloming <rafaels@redhat.com>:
>>
>>>> I could buy into s/M/0./ for everything (but not s/M/1./). I know some
>>>> people are opposed to releasing 0.x versions for marketing reasons,
>>>> but that essentially removes any useful information from the rev.
>>>
>>> I agree, and personally I don't think marketing should enter into the
>>> version number discussion. I think once you let marketing in, you've
>>> removed
>>> all hope for sane and useful version numbers. ;)
>>
>> I don't think the 1.x argument is about marketing, really. It's about
>> conveying information that reflects accepted understanding of the
>> meaning contained in the number. A 0.x release implies to many people
>> a low level of maturity and stability. Certainly looking at the Java
>> broker and client, only because I a most familiar with those, I know
>> that they have many production installations today delivering
>> business-critical messages. By labelling that 0.x I think it is
>> painting a false impression of the maturity of the software - which is
>> now several years old. Are we really saying that after three years
>> qpid isn't even 1.x?
>>
>> I do also agree that 1.x implies a certain level of API compatibility
>> - but I can smugly say that I have consistently argued on this forum
>> that building an API that is closely tied to AMQP is insane. Maybe
>> this implies that for the next release the non-Java languages need to
>> focus on the API design. Or we should be comfortable moving to 2.x
>> relatively quickly as the API evolves.
>
> If we had *some* API other than JMS then labeling it 1.x might be reasonable
> even if we expect to have a 2.x coming up, but for me at least, what we have
> doesn't constitute enough of an abstraction to be labeled a 1.x since that
> implies we have confidence in our ability to go from 1.x to 1.x+1 without
> breaking the API, and I don't think we're there yet.
>
> I think if you're concerned with the 0.x moniker implying instability then
> maybe we should stick with Mx and make it a high priority to build out the
> non Java client APIs.

I'm +1 on that.

Implementing an API that exists on each platform for messaging seems
like the way to go.
Obviously only if there is such an API. I know at least C# has a
standard System.Messaging but does Ruby, Python and C++ have simlar
platform Messaging APIs?

I don't think we should be making one up, especially as some of us our
JMS API tainted.

I'd say the best way to go is to reuse already well known and accepted
APIs where we can. Is someone willing to look in to what APIs we could
use?

Martin

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



-- 
Martin Ritchie

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


Mime
View raw message