On 18/01/07, Gordon Sim <[EMAIL PROTECTED]> wrote:
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.
Yes, I think the problems have been caused by a lack of clarity of what we are tracking/heading towards. We are notionally heading towards 0-9 but 0-9 does not include everything we need to be JMS compatible, and JMS compatibility was a goal for qpid's next release. I think that we are in a position where our next release of qpid (i.e. M-release) can only sensibly be with 0-10.
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.
Unless that is an incompatibility introduced by a breaking change in the spec we are tracking towards? e.g. let us assume for the purposes of this discussion that field table type enhancements is in AMQP 0-10. In that case I would not view it as a bug that trunk java does not interop with trunk C++ at a given point in time (although there is obviously a task there for C++ to implement that change).
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).
Yes, a clear analysis of our multi-version strategy is almost certainly required... RG
