[Mono-dev] To split or not to split Mono?

[Ben Maurer]

On Thu, 2005-11-03 at 22:24 +0100, Kornél Pál wrote:
> The problem is that some modules are evolving much faster than the others.
> It's a good idea to split them, but there could be daily binary releases in
> addition to source code snapshots. As I know packaging is automated so it
> could be possible to release binaries as well. Of course they were unstable
> just like daily source code but I'm sure that there are people who need
> this.

Yes, that'd be possible (I meant to do that when I started the packaging
stuff, it's in Wade's hands now).

I'd point out that splitting up mono would make this much easier:
everything except the core part is OS/Distro/Arch independent. In fact
we could just release *tarballs* of the .dll files and have a script to
install the dlls into the gac correctly, or something.

This would actually make it easier for people who want to hack on/test a
patch on some part of mono to do if they run from rpms. For example, if
I want to write a patch for System.Web, I can install mono-core from
rpms, and then check out the web portion from svn, build and install it.
(in theory I guess you might be able to get away with this today, but
right now it's an advanced hack, once we split it could be the norm).


Anyways, there are clearly many advantages of the split, what is
probably more helpful in this thread is:
      * Cons to splitting
      * Some thinking about logistics (eg, do we have a unified release
        of all the parts of mono (mono poly ;-) every N months, or are
        the components completely disjoint release cycles)

One thing that jonp and I mentioned briefly on irc today under the cons
category: support. With a Chinese menu style of release (pick one from
column a, one from column b...) we will get more configurations to test
and may start seeing weird interactions between versions. One way to
handle this sanely this would be to have a clear list of 1-3
"acceptable" combinations. This would fit in with the concept of a
release of the complete mono stack: mono 2.0 would be when we put the
new runtime, and all class libs in the "stable" configuration.

Miguel has suggested a split along functional lines: this part does gui,
that part does databases, etc. This seems to have alot of logical
appeal, and it is the easiest for a user to understand. However, the
goal is to allow us to update a component that is moving rapidly while
isolating the core components from potentially destabilizing changes.
For example Atlas would surely be part of a "web" component, but clearly
there are different stability requirements for Atlas and System.Web. It
might also be nice to be able to update the 2.0 packages without
affecting 1.0 packages (however, this would be hard unless the stable
2.0 mscorlib is very good, as we can't just push in a new corlib). 

-- Ben