<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 10, 2013 at 12:54 PM, Mircea Markus <span dir="ltr"><<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 10 May 2013, at 10:06, Manik Surtani wrote:<br>
<br>
> There seems to be a bit of confusion on this thread. The things I hope to achieve here are:<br>
><br>
> 1. De-coupled release cycle.<br>
> 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.<br>
><br>
> 2. Smaller download.<br>
> 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.<br>
><br>
> 3. Scalability.<br>
> 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.<br>
<br>
</div>well summarised.<br>
<div class="im"><br>
><br>
> 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.<br>
</div>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.<br></blockquote><div><br></div><div>I think configuring the cache stores build to run on every snapshot build should be enough - just like Hibernate Search.<br>
</div><div>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.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">><br>
> 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.<br>
</div>+1<br></blockquote><div><br></div></div>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?<br></div><div class="gmail_extra">
<br></div></div>