+1, also only the gui-demo should be in the main repo. All other examples/demos should be moved to quickstarts or their own repos.
Tristan On 11/18/2013 09:15 AM, Galder Zamarreño wrote: > On Nov 15, 2013, at 2:02 PM, Sanne Grinovero <[email protected]> wrote: > >> +1 >> (as I've always been, damn my "pessimistic" opinions) >> >> However there is an alternative. If I recall correctly, one of your >> motivations for the split was to not keep maintaining all the >> non-essential components. >> I really like that idea, I just think it was implemented the wrong way. >> >> If you identify which components are non-essential (and you don't need >> them on the release day), you should keep them out but unlock them to >> a different version numbering, and especially never ever depend on >> snapshot versions. >> >> Let's try define the requirements: >> - any project should compile successfully out of the box >> - last minute "surprises" before a release needs to be done is not manageable >> >> You could get this easily if you allow the projects which are in a >> different repository to lag behind: you can't require to release those >> other projects each time you release an Infinispan "core" version. >> Which inherently implies that if you have something which is essential >> for a core release, it needs to be moved back to catch failures early >> on and keep them in perfect sync. >> >> Other module maintainers would then catch up on compatibility breaking >> changes of Infinispan core as (and when) they can. We can of course >> have a goal of keeping aligned quickly, but it should be optional >> (i.e. non-blocking for innovation and progress on the core module). > + 1 to all said above and Mircea's suggestion. > > The thing is that Infinispan Server, and a subset of the cache stores really > need to be released at the same time as Infinispan core. All those modules > would benefit from living in same repo, making the compilation, CI and > release much easier. Some examples: Level DB store needs to be brought back, > whereas Cassandra cache store can live on its own. > >> It's perfectly doable, all our other projects depending on Infinispan >> have lived well so far, with the occasional pain to fix some backwards >> compatibility issue but that's part of the dance. For example Search >> depends on Hibernate ORM, JGroups and Infinispan.. we try to catch >> backwards compatibility with ad-hoc CI jobs but it's not going to >> catch all problems, nor it's our intention to "block" other projects >> from innovating: it's rather for us to be aware of possible problems >> asap.. but none of these problems are allowed to prevent us to release >> early and often. >> >> [BTW the reason the Search case isn't perfect is because we target >> specific platforms like AS/Wildfly, not necessarily the latest >> Infinispan] >> >> Cheers, >> Sanne >> >> >> On 15 November 2013 12: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 > > -- > 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 > _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
