[Mono-dev] To split or not to split Mono?
lukas at pmad.net
Thu Nov 3 16:06:38 EST 2005
I think splitting is a very good idea. I use Mono.Cairo in an
application I'm developing at the moment. The problem is that it needs
Mono.Cairo from SVN and is therefore pretty hard to get running for a
normal user. Having to wait until it hits an official Mono release is a
On Thu, 2005-11-03 at 15:49 -0500, Miguel de Icaza wrote:
> 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
> 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.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list