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)