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).
