I've created ISPN-3728 to track this. On Nov 18, 2013, at 2:16 PM, Tristan Tarrant <[email protected]> wrote:
> +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 Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
