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

[Kornél Pál]

Hi,

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.

BTW when will Mono 1.2 be released?

Kornél

----- Original Message -----
From: "Miguel de Icaza" <miguel at novell.com>
To: <mono-devel-list at ximian.com>; "Ximian Mono List"
<ximian-mono-list at lists.ximian.com>
Sent: Thursday, November 03, 2005 9:49 PM
Subject: [Mono-dev] To split or not to split Mono?


> 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
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>