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

[Manik Surtani]

On 20 Aug 2008, at 17:26, Brian Stansberry wrote:

> Manik Surtani wrote:
>> On 20 Aug 2008, at 04:28, Bela Ban wrote:
>>> I added an item to our agenda for Brno, so we can discuss it there  
>>> (on FRI, but this will get shifted around anyway)
>> Hmm, re: 3.x, I think we need to move a bit quicker than that.  I'm  
>> holding back 3.0.Beta1 until we decide on this approach, since it  
>> will affect whether:
>> 1.  I revert to JBC 2.x interfaces
>> 2.  move 3.x interfaces to a new package
>> 3.  stick with new 3.x interfaces and rely on an adapter package.
>>
>> Thoughts?  Anyone want to take a vote on this?  :-)
>
> Thoughts, not vote.
>
> #2 I've gotta figure having 2 interfaces that are mostly equivalent  
> would have to cause problems.
>
> #3: AIUI, that means creating a jarjar'd 3.x and an adapter jar that  
> exposes the 2.x API. Pro: end user apps have a stable API between  
> minor AS releases. Con: Hibernate and/or EJB3 integration is likely  
> stuck using 2.x APIs/the adapter, unless those projects are willing  
> to support and integration module that uses the jarjar'd 3.x  
> packages. TBD, after CR2 is out, since CR2 is near at hand and is my  
> focus.
>
> #1, I don't know how much that screws you up.

#1 seems like the cleanest/easiest thing as far as the AS and other  
API consumers are concerned, even if it does pollute JBC API.  I plan  
to spend a few cycles today revisiting these and seeing what can be  
done to maintain compat.  For the most part (Cache, Fqn, CacheFactory)  
this should be ok, just would mean having a lot of deprecated methods  
around, but for the Eviction and Region interfaces it could be  
tricky.  Could mean some sort of internal adapter.

Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org