Re: [jbosscache-dev] Let's make 3.0 backwards compatible
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#...
>
> 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-cac...
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com