[jbosscache-dev] Let's make 3.0 backwards compatible

[Brian Stansberry]

Manik Surtani wrote:
> 
> On 18 Aug 2008, at 18:39, Jason T. Greene wrote:
> 
>> One of the headaches we cause our users, include the AS5 clustering 
>> team, is breaking API compatibility on every major release. This is 
>> probably the biggest reason why getting JBC3 into an AS5 release is a 
>> non-option.
> 
> Not just API - with MVCC, it is also the default configs shipped.  
> Although since 3.0 supports legacy locking schemes, it could always be 
> configured with the legacy locking schemes and a README included 
> explaining how to change these configs.
> 
>> See users complaining:
>> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171065#4171065
>>
>> I propose that we make 3.0 100% backwards compatible with JBC 2.x. 
>> This will improve adoption, and means we stand a chance at becoming a 
>> part of an AS5 release. IMO, there is little justification for API 
>> changes since our biggest feature / release goal doesn't require it. 
>> Also, since we have some API impacting features (partitioning, etc) 
>> scheduled for the next major release, it is very possible that we 
>> would end up breaking the API twice.
> 
> Agreed about the backward compat.
> 

<snip/>

If this were doable, it would be a good thing. Been thinking a bit more 
about how to get JBC 3 in a formal AS 5.x release, x > 0. There's really 
3 issues:

1) Compatibility w/ AS's own code that uses JBC. If it's a new AS 
release the integration code can change, so this isn't a big technical 
issue.  But, obviously, the more backward compatible JBC is, the less 
work there is to integrate a new version. :-)

2) Compatibility w/ user apps that use JBC that people have deployed in 
AS 5.0.0 . We don't want to break other peoples' apps in a minor AS 
release.  This I think is the big issue; hadn't really thought much 
about it until Jason started this thread.

3) Configuration compatibility. In general, massively reworking configs 
in a minor AS release isn't the best. Some changes, OK, but a total 
rework isn't the best as it's really disruptive to whatever 
configuration customization people already have. See [2] for the config 
files that currently drive the AS's usage.


The discussions we've been having around SPIs for AS' JBC usage are 
really more helpful for external projects like Hibernate and EJB3, or 
for allowing informal upgrades of JBC outside an official AS release 
(e.g. upgrade the web session integration even though the official AS 
still uses JBC 2).

[1] 
https://svn.jboss.org/repos/jbossas/trunk/cluster/src/resources/jboss-cache-manager.sar/META-INF/
-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com