[Mono-dev] To split or not to split Mono?
monoman at gmail.com
Thu Nov 3 16:44:57 EST 2005
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:
> 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
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.
More information about the Mono-devel-list