Tim Fox wrote:
Adrian Brock wrote:
> On Tue, 2009-02-17 at 14:00 -0600, Jason T. Greene wrote:
>
>> Tim Fox wrote:
>>
>>> Jason T. Greene wrote:
>>>
>>>> I really wish we could. Tim said theres pretty much no was JBM2 can
>>>> make Beta1, but it could make CR1. The question is, would it be
>>>> stable and TCK compliant enough that it doesn't end up delaying GA?
>>>>
>>> No, JBM 2.0 is a major release and is not compatible with JBM 1.4.
>>> That's why we can't replace JBM 1.4 in a minor release since AS
>>> minor versions need to be compatible, and why it's being offered as
>>> a technology preview, not replacement for default JMS provider.
>>>
>> Where did this rule come, and what level of compatibility are we
>> talking about? We do need EE API compatibility, and ideally all of
>> our public APIs should be BC (so that developers don't have to
>> rewrite their apps), but IMO we don't need wire protocol
>> compatibility. You already can't cluster 5.1 and 5.0 together.
>>
>> The insane levels of compatibility should be reserved for EAP, but
>> 5.1 is the source of an EAP major version, so it doesn't need it.
>>
>>
>
> No. JMS is a client/server protocol not a server/server protocol.
>
Ah, but the compatibility requirements go beyond JMS (that API has been
static for years as you know).
What we were told at the time was that for minor releases, EAP requires
compatibility for the JMS stuff, but also all the other stuff we add
beyond JMS (read messaging JMX interface for messaging in 1.x).
Now.... if EAP is going to consume AS community version in lock step
fashion, then it also will need the same compatibility requirements. Ouch!
See the still ongoing EAP compatibility discussion on core. The short
answer is that it's not required between major versions (provided there
is a migration guide). Therefore we can break it in 5.1, since it's the
first EAP 5 release. Any future 5.x release though will have to be more
careful.
--
Jason T. Greene
JBoss, a division of Red Hat