[infinispan-dev] merging all the github projects back?

[Galder Zamarreño]

On Nov 15, 2013, at 2:02 PM, Sanne Grinovero <sanne at infinispan.org> 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 <mmarkus at redhat.com> 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
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org