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

[Rafael Teixeira]

I think that splitting out anything in the MS-compatible stack will
turn things harder at the user end, we have more control in the other
things to decide a good, or at least reasonable, split.

I would indeed keep everything MS keeps together similarly packed and
released in an apropriate schedule. But would suggest WinForms to have
separately-scheduled superceding updates, as it's API is (or at least
should be) frozen so that only implementation is corrected/added on
each release/update but no breaking API changes need to go into it. I
know you don't like it Miguel, but I would stub WinForms completely to
have it really API-Frozen matching the 1.1 MS API, so that updates can
just be deployed over (as MS Service Packs normally do) existing
assemblies (GAC'ing as needed).

Things that have a floating API like Mono.Posix/Mono.Cairo I agree
that should be split, and I don't see much of problem with that.

My 2 cents,


On 11/3/05, Miguel de Icaza <miguel at novell.com> wrote:
> 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
>


--
Rafael "Monoman" Teixeira
---------------------------------------
I'm trying to become a "Rosh Gadol" before my own eyes.
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
It hurts!