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