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

[Miguel de Icaza]

Hello,

    Today a discussion about including a new library into Mono class
libraries happened on #mono or #monodev channels.   In the past we have
been fairly open to bundling more useful libraries as part of the "mcs"
module.  But there are a few problems.

    By keeping all of Mono in a single package (runtime, compilers, core
libraries, GUI libraries, web libraries, database libraries and
"others") it is making our future maintenance of code more difficult.

    See, currently we have various different degrees of maturity in
Mono: the core is very stable and it mostly gets bug fixes and
performance fixes.  Other areas (Mono.Posix, Mono.Cairo) are still in
relatively heavy development and refactoring and some others are still
fairly incomplete (Windows.Forms).

    When Mono 1.2 comes out, we will have to branch the tree at 1.2, and
backport all of the fixes from HEAD to the branch on an ongoing basis.
I have no problem doing this for the core of Mono, but the more active
areas of Mono will likely be fairly large chunks of code that we would
have to backport and maintain.

    So am wondering whether we should split mcs/class into various
packages that can be released independently.  This would minimize the
branch maintenance pain and means that when we fix a bug in
Windows.Forms we do not have to re-issue the whole Mono stack.

    Doing the actual split would still require a considerable amount of
work: not only splitting it, but doing all the build system and
packaging changes to cope with this.

    I had initially proposed "GUI", "Server", "Database" and "Core", but
this is not necessarily a good split.  Database code for example
requires Windows.Forms to be around.   So maybe we need a different
split.

    Am not sure if we will split Mono, but if we do, I have already
chosen the names for the modules: Red, Green, Blue and Yellow.

Miguel