[infinispan-dev] moving (some) cache stores in a different github repository

[Emmanuel Bernard]

I'm personally more aligned with Sanne's concerns. In particular, you should be able to release really quickly and the release cycle separation seems like a sign that you cannot achieve that today. 
We had a very bad experience with Hibernate around a matrix of compatibility between core, annotations and entity manager. Not sure such a model works in practice. Despite best efforts we did break things between micro versions. 
An intermediary mode is the one Lucene has with a core and a contrib distribution. Not yet stable or peripheral modules and all in contrib. but in practice people tend to wait for the contrib to be released for a given core and projects end up using one or the other of the contributions. 

Emmanuel

On 10 mai 2013, at 11:54, Mircea Markus <mmarkus at redhat.com> wrote:

> 
> On 10 May 2013, at 10:06, Manik Surtani wrote:
> 
>> There seems to be a bit of confusion on this thread.  The things I hope to achieve here are:
>> 
>> 1.  De-coupled release cycle.
>> Most of our releases include new versions of XYZCacheStore, even though there are no changes to it.  This creates noise, IMO.  Cache Stores should only be released when there are changes made to it.  Now this wasn't so much of a problem when we just had a small handful of cache stores, but as this increases, this becomes even more noisy/confusing to end-users.
>> 
>> 2.  Smaller download.
>> Not everyone uses all cache stores; not including everything in a zip ball will reduce download size.  But as pointed out before, this can be achieved via other techniques.
>> 
>> 3.  Scalability.
>> Moving cache stores to separate repos will allow us to add more cache stores, accept more contribs for experimental cache stores, build out a richer ecosystem.  Right now, we restrict the number of cache store impls to prevent bloat of the core distribution.
> 
> well summarised.
> 
>> 
>> This does *not* impact the developer at all, IMO.  CI (and test) runs on core will still involve testing all *non-experimental* cache stores.  I think this should happen every time and not just daily.
> I don't think we need to do it on every build. But this is more of an configuration option and we can do it if needed.
>> 
>> In terms of a compatibility matrix (which cache stores work with which versions of core), we'd need to devise a scheme.  For example, match on major.minor, like CacheStore 5.3.x will work with any version of core 5.3.x.
> +1
> Cheers,
> -- 
> Mircea Markus
> Infinispan lead (www.infinispan.org)
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev