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. - Aidan [1] http://apr.apache.org/versioning.html [2] [2] This is essentially kernel style, without the stable/unstable connotations of odd/even releases. -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
