<div dir="ltr">Sorry Sanne for ignoring your message, I meant to send the reply to Manik's :)<div><br></div><div>I agree that depending on SNAPSHOTS from another repository is not a good idea. After all, we couldn't even make the dependencies work in CI for the jobs we have now - the REST cache store's build still fails because it can't find the infinispan-persistence-parent-6.0.1-SNAPSHOT POM in the repository.</div>
<div><br></div><div>In this case we did have an option: we already have a compatibility layer that allows cache stores to use the old, stable SPI, so the cache stores could have depended on the latest Alpha/Beta/CR version, and (at least in theory) the server could have kept on using the 5.2.6.Final version of the cache stores until the final version of the core was released.</div>
<div><br></div><div>The problem, I guess, is that we still want to release Infinispan Server on the same day as Infinispan "Embedded", and we also want it to use to use the latest and greatest cache stores. If we don't change that policy, we can't use your suggestion.</div>
<div><br></div><div>Cheers</div><div>Dan</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 20, 2013 at 1:43 AM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Manik,<br>
the problem the team has been facing past week is that the other<br>
modules are depending on a -SNAPSHOT version, and after having done<br>
some final touches to the modules in the core repo, we then find out<br>
that the other modules don't build anymore.<br>
<br>
This happened several times, and while it's normal for dependant<br>
projects to occasionally break, it's not so nice that the current<br>
structure doesn't allow for it to be spotted, or managed time-wise: it<br>
is important to be able to release at any point in time, but having<br>
potential "surprises" in different modules makes it hard to predict<br>
how long it will take to get to a stable tag.<br>
<br>
My suggestion is not to necessarily return all external modules in the<br>
core repository, but rather to make sure the modules which are<br>
separately also have the benefit of a different release cycle, so that<br>
you can always release any module at any time. This could mean that<br>
they have different version numbers but not necessarily: we could make<br>
it a convention to release compatible optional modules using the same<br>
version. For example - the optional CacheStore implementation for<br>
Infinispan 6.0.0.Final are released also as 6.0.0.Final but not<br>
_necessarily_ on the same day of the core module. Probably works best<br>
to have a same major,minor number, and be flexible with micro<br>
releases.<br>
<br>
You'd never want to depend on a snapshot version unless it's a module<br>
in your same repo. As mentioned, if a new Infinispan "improvement"<br>
breaks the Hibernate Search build, I have the option to decide to not<br>
upgrade; you don't have this flexibility if you're depending on<br>
snapshots.<br>
<br>
Cheers,<br>
Sanne<br>
<div class="HOEnZb"><div class="h5"><br>
On 19 November 2013 23:17, Manik Surtani <<a href="mailto:manik@infinispan.org">manik@infinispan.org</a>> wrote:<br>
> As in, for easy refactoring? True that helps. But it doesn't help you with<br>
> modular releases.<br>
><br>
><br>
> On 19 November 2013 15:00, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
>><br>
>> That only half-solves the problem: having everything in the same IDE at<br>
>> the same time is more preentive.<br>
>><br>
>> On 19 Nov 2013, at 22:44, Manik Surtani <<a href="mailto:manik@infinispan.org">manik@infinispan.org</a>> wrote:<br>
>><br>
>> Can't this be achieved by checking out and building all relevant repos?<br>
>> This could be scripted.<br>
>><br>
>><br>
>> On 15 November 2013 04:43, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
>>><br>
>>> Hi guys,<br>
>>><br>
>>> Given all the compiling problems we had since we've split in multiple<br>
>>> github repos (server, stores and embedded) makes me think that the split<br>
>>> wasn't such a great idea after all( and that I was hmm, wrong). Shall we<br>
>>> move everything back into a single repo? We can still keep different CI runs<br>
>>> for cache stores, server etc, but at least all this builds will compile<br>
>>> everything.<br>
>>><br>
>>> wdyt?<br>
>>><br>
>>> Cheers,<br>
>>> --<br>
>>> Mircea Markus<br>
>>> Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> infinispan-dev mailing list<br>
>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div>