qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: version number proposal
Date Tue, 03 Feb 2009 12:05:31 GMT
Aidan Skinner wrote:
>> I'm of two minds on this. On the one hand I think your proposal probably
>> most accurately reflects the reality of the current situation. On the other
>> hand, I don't think the current situation is really a great place for us to
>> be as a project.
> I think version numbers which reflect reality is probably a plus. I
> don't think it would be detrimental to the one team, one project, one
> qpid goal. There are definately issues there, but I don't think
> independently varying version numbers would add to those.

Part of my point is that the extent to which they reflect reality 
depends on where you want things to be going.

One view is that JMS is API stable, and other clients are not, therefore 
JMS gets a nice stable version number, and the other components don't. 
However in some ways that's a bit missleading since we're not trying to 
version the JMS API (we don't need to, it already has its own version 
number), we're versioning our *implementation* of JMS, and to a much 
greater extent the maturity of our *implementation* does depend on the 
other pieces of the project, e.g. the broker, and the level of interop 
with other clients, and one version number better reflects *that* reality.

>> In particular, one of the core goals of qpid is to provide a consistent
>> cross-language messaging experience, and that includes equivalently stable
>> and similar looking/feeling APIs across all the client languages we support.
> I'm not sure that similar looking/feeling APIs are really desierable.
> I'd rather see idiomatic APIs that feel comfortable and natural in the
> language than shoe-horning JMS into C++.

I'm not sure what would require shoe-horning. The JMS API is very 
simple, and could easily be translated idiomatically into any of our 
current client languages, e.g in ruby it would be quite possible to 
model connection, session, producer, consumer, and message and yet still 
have consumer.on_message {|m| blah ... } rather than 

That said, my statement in no way implied that we should mindlessly 
translate JMS into the other languages, simply that we need some set of 
APIs that are at a similar level of abstraction such that they can each 
support multiple protocols underneath.

> The fact of the matter is that the various clients and brokers are at
> differing levels of robustness, internal stability and API stability
> and that's not something that I really see changing anytime soon.

Actually at the moment I think they're all fairly close. There are 
really only two outliers: JMS and dotnet. JMS being more API stable due 
to being JMS, and dotnet being in an exceptional category at the moment 
since we haven't really settled on how we're going to provide something 
there in a sustainable manner going forward.

IMHO the appropriate way to make the situation with the JMS client clear 
is to actually state on our download page that it is a JMS client, and 
maybe even put JMS in the artifact name. This will have infinitely more 
meaning than any version number choice.

As for dotnet, I think that probably deserves its own discussion, since 
the issue there is really more about how we are going to maintain the 
thing going forward, and less about what it's current version number 
should be.

>> So for me, I'd either stick with the Mx version numbers, or use a pre 1.0
>> version numbering scheme until we've reached that goal of a consistent cross
>> language messaging experience, and only from there move into post 1.0
>> territory.
> 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. ;)


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

View raw message