Aidan Skinner wrote:
On Mon, Feb 2, 2009 at 11:15 PM, Rafael Schloming <[email protected]> wrote:
I think this would make a bit more sense. For me at least versions like 1.5
and 1.6 imply a level of API compatibility and client/server interop that
goes beyond what we currently test for in our releases.
I think we should adopt APR[1] style version numbers, they convey
meaningful information and are widely understood.
As a result of this, I think we should have different version numbers
for the individual components. The C++ API, the Java API and the .Net
API are all rich APIs which vary independently of the protocol
version. The C++ client from M4 is not compatible with the version
from M3, but both implement 0-10. The python and ruby clients are much
lower level, and don't vary as much. The Java client primarily exposes
JMS and the API doesn't vary between M2, M3 and M4 despite adding
0-10.
Between M3 and M4 the C++ client API change would have required a
major revision bump. The java client didn't change in this way, so
would have had a minor bump. We'll quickly get into a situation where
the components have a variety of version numbers.
To make it clearer what a release is, I propose a release revision.
Either a monotonically incrementing integer, such as we currently have
or an ISO-date. At this point Apache Qpid quite closely resembles an
OS distribution in terms of components brought together to form a
functional release. This model has worked well for those projects, and
I think it would work for us.
As an example, M4+1 might be "Apache Qpid 5" or "Apache Qpid 2008.04"
and contain qpid-java-1.4.0, qpid-cpp-1.4.0 and qpid-python-1.4.0
M4+1+1 might be "Apache Qpid 6" and contain qpid-java-1.5,
qpid-cpp-2.0 and qpid-python-1.4.1. The main number is useful for
talking about the release to the outside world, the individual package
numbers are useful when trying to figure out what you might need to do
to make your application work with a new version of qpid.
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.
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. Unfortunately, to date we haven't been particularly good at
cross language coordination, and so in some respects the project starts
to feel like several completely independent sub-projects. This of course
makes it tempting to treat Qpid as a distro/umbrella project as you
propose, but I can't help but feel that doing that is giving up on an
important goal.
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.
As an aside, this does remind me a bit of the perpetual directory layout
conversation where someone (I think usually Rob) says that it would make
more sense to split things up between the broker and the clients than to
split things up by language. I think the same argument could be made for
component versions as well, e.g. one shared version number across all
the clients, and one for each broker. That division would certainly
reflect the aforementioned goal.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
