Re: [infinispan-dev] moving (some) cache stores in a different github repository
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev