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
consumer.setMessageListener(...).
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. ;)
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
