On Nov 15, 2013, at 2:02 PM, Sanne Grinovero <sanne(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org