[infinispan-dev] moving (some) cache stores in a different github repository

[Dan Berindei]

On Fri, May 10, 2013 at 12:54 PM, Mircea Markus <mmarkus at 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.
>

I think configuring the cache stores build to run on every snapshot build
should be enough - just like Hibernate Search.
But if we find that we break the cache stores too often, we could change
the pull request build to include the cache stores as well.



> >
> > 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
>

Wouldn't that require us to release a JBDM cache store version 5.3.0 even
if the JDBM cache store didn't change at all between 5.2.0 and 5.3.0?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130510/53ada4e5/attachment-0001.html