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 [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
