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