Hi Aidan, As Rafi pointed out, your proposal seems like a good fit to handle the current situation. However the current situation is very confusing for potential users and newcomers to the project. Having gone through 5 releases and looking at the queries on the user/dev list, my experience is that release by language has not quite worked. Instead we have ended up with a very confusing matrix in our download page and this has confused potential users to no end. If we continue down this path we will end up with a more confusing matrix of client/broker versions (not mentioned the growing management tools).
As I have suggested in another thread I think we need to do component releases in the future. i.e Have separate downloads for broker/clients/management tools than one monolithic file. When we move to such a model it makes sense (As Rafi suggested) to have a common version number for brokers and one across all clients and one across all management tools. This will enable the clients, brokers and the management tools to evolve independently. The above scheme will make it easy for potential users to make a clear decision. It also provides them with a clear path to upgrade and maintenance. Regards, Rajith P.S I also think that we need to organize our dir structure (as Rafi/Rob pointed out) and the wiki as client/broker/management tools. Eventually a particular management tool should work with both java and c++ brokers. So it make sense to partition the wiki/documentation space by component rather than language. Right now the wiki is by language and it's kinda of all over the place. On Mon, Feb 2, 2009 at 8:34 PM, Rafael Schloming <rafa...@redhat.com> wrote: > Aidan Skinner wrote: > >> On Mon, Feb 2, 2009 at 11:15 PM, Rafael Schloming <rafa...@redhat.com> >> 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:dev-subscr...@qpid.apache.org > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
