On Nov 20, 2013, at 11:03 AM, Dan Berindei <[email protected]> wrote:
> When it comes to IDEs, I'd rather remove some more modules from the main > project in order to make it more responsive and easier to use. Launching a > test from IntelliJ takes minutes to build (or parse, or analyze, or whatever) > everything, when it works. Extra dependencies on old versions in the > compatibility modules broke the "Analyze stacktrace" feature, which used to > be very nice for analyzing logs. ^ Isnt't that a problem with the IDE which is messing up the code that's really in use? > > I'd argue that having the cache store builds break in CI actually serves as a > warning that we are breaking the API/SPI for our users. I don't think making > API/SPI breakage easier should be the goal of our setup. > > > > > On Wed, Nov 20, 2013 at 1:43 AM, Sanne Grinovero <[email protected]> wrote: > Hi Manik, > the problem the team has been facing past week is that the other > modules are depending on a -SNAPSHOT version, and after having done > some final touches to the modules in the core repo, we then find out > that the other modules don't build anymore. > > This happened several times, and while it's normal for dependant > projects to occasionally break, it's not so nice that the current > structure doesn't allow for it to be spotted, or managed time-wise: it > is important to be able to release at any point in time, but having > potential "surprises" in different modules makes it hard to predict > how long it will take to get to a stable tag. > > My suggestion is not to necessarily return all external modules in the > core repository, but rather to make sure the modules which are > separately also have the benefit of a different release cycle, so that > you can always release any module at any time. This could mean that > they have different version numbers but not necessarily: we could make > it a convention to release compatible optional modules using the same > version. For example - the optional CacheStore implementation for > Infinispan 6.0.0.Final are released also as 6.0.0.Final but not > _necessarily_ on the same day of the core module. Probably works best > to have a same major,minor number, and be flexible with micro > releases. > > You'd never want to depend on a snapshot version unless it's a module > in your same repo. As mentioned, if a new Infinispan "improvement" > breaks the Hibernate Search build, I have the option to decide to not > upgrade; you don't have this flexibility if you're depending on > snapshots. > > Cheers, > Sanne > > On 19 November 2013 23:17, Manik Surtani <[email protected]> wrote: > > As in, for easy refactoring? True that helps. But it doesn't help you with > > modular releases. > > > > > > On 19 November 2013 15:00, Mircea Markus <[email protected]> wrote: > >> > >> That only half-solves the problem: having everything in the same IDE at > >> the same time is more preentive. > >> > >> On 19 Nov 2013, at 22:44, Manik Surtani <[email protected]> wrote: > >> > >> Can't this be achieved by checking out and building all relevant repos? > >> This could be scripted. > >> > >> > >> On 15 November 2013 04:43, Mircea Markus <[email protected]> wrote: > >>> > >>> Hi guys, > >>> > >>> Given all the compiling problems we had since we've split in multiple > >>> github repos (server, stores and embedded) makes me think that the split > >>> wasn't such a great idea after all( and that I was hmm, wrong). Shall we > >>> move everything back into a single repo? We can still keep different CI > >>> runs > >>> for cache stores, server etc, but at least all this builds will compile > >>> everything. > >>> > >>> wdyt? > >>> > >>> 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 > >> > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > 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 -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
