qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: [java] AMQP compliance and the Java client
Date Thu, 18 Jan 2007 10:59:36 GMT
Robert Greig wrote:
> My own view is that we must not lose sight of the fact that qpid is
> tracking a specification that is still evolving rapidly - currently
> version 0.8 with 0-9 in progress. Also the qpid codebase itself is
> being changed a lot, and we have only had one milestone release. Given
> that rate of change, is it sensible for qpid *trunk* to track an AMQP
> specification? Or even offer any guarantees of interoperability?

I think we are by definition 'tracking' some version of the 
specification as we rely on the xml section for code generation (dynamic 
or otherwise), the question is how compliant we are with respect to the 
version currently in use. (An interesting aside is whether we are in 
violation of the copyright if we edit the xml spec after it is published?)

As the trunk is a moving target I don't think we can 'guarantee' 
anything (not even that it builds at any point in time!). I do think we 
should aim as far as possible to be compliant in at least a basic sense 
with the specification version in use.

> How do the following rules sound to people:
> 1) Qpid releases will support a particular published version of the
> AMQP specification.

Agreed, as far as feasible and we should aim to document any gaps or 
failings in support for each release.

> 2) Qpid trunk should be considered a work in progress that may not
> support a published AMQP specification. People using trunk are using
> bleeding edge software.

I would view anything that breaks compatibility (as opposed to anything 
that extends functionality in a non-standard way) as a known bug. It is 
to be expected that there may be known bugs on the trunk at any time, 
but the aim should always be to have these clearly highlighted and a 
plan in place to fix them as soon as practicable.

> 3) Up to AMQP 1.0 (whenever that is published) Qpid will not offer
> backwards compatibility between versions. After AMQP 1.0 is released,
> qpid releases will be backwards compatible for major versions of AMQP.

Agreed. (It may be useful nearer the 1.0 release to try an validate any 
mechanisms we might have created for multi-version support by 
implementing two similar versions, but that would be more for our 
benefit than for our users).

View raw message