John O'Hara wrote:
That's fine in principle if the trunk will fully support 0-8 transport and
WIP transport; in compliance with agreed 0-9 spec.
If the new code is 0-8 only, that's too big a risk to swallow without
proving it all out on the branch first.
If we want to make changes to the WIP transport, as may be suggested by the
recent lobbying by Cisco and iMatix, then we shouldn't be committing that
level of churn to the mainline.
We need to reach some agreement on this.
Myself and Robert are worried that dropping the 0-8 transport from trunk at
this point will cause lots of immediate issues which prevent development of
other important functions like improved persistence and fixing errors in TX
handling.
Can you suggest a way forward that mitigates my concerns here?
John
I should point out that from the point of view of code stability and
given the current implementation it's almost meaningless to support
basic and message at the same time since the Java client implementation
has to pick one or the other, and obviously on the 0-9 branch it uses
the message class, so while we could add broker support for basic, it
would essentially be dead code. In theory we could run old Java clients
against the broker to test it, but not even this would really work due
to field table incompatibilities.
It's important to understand that what we've done on the branch isn't
actually deleting basic per se, we've renamed the basic event handlers
to respond to message events. All the same code and functionality is
there, it simply uses different class/method ids on the wire, and while
we could copy the event handlers in order to keep basic functioning,
IMHO that would ultimately lead to more bugs since we'd have two copies
of the event handlers, one of which would be dead code.
We could have taken a fancier approach that let us switch between
message and basic on the fly, but this would have been a bigger more
disruptive change. Once the branch is landed if we decide we don't want
to release without support for basic we can restructure the event
handlers in this way, but as long as we're on the branch there is
significant reason to avoid making any more structural changes than
necessary in order to minimize the effort and impact of landing the branch.
Ultimately I think the only real measure we have for the stability of
the code base is the tests themselves. So given this, I'd like to
suggest that all tests passing is the appropriate criteria to use for
landing the branch. I think delaying beyond this point will be
significantly counterproductive since we won't really learn anything
about the stability of the branch, and the delta between the branch and
trunk will continue to grow making the eventual merge both more work and
more destabilizing.
--Rafael
