On Nov 20, 2013, at 12: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. Essentially, we'd bring back to infinispan/ repo those bits that are release in under the same release cycle, which are: - infinispan/ - infinispan-server/ - infinispan-cachestore-leveldb/ - infinispan-cachestore-rest/ I'd also consider bringing in protostream… The rest would stay in their own repos and be released as needed. > 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 -- 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
