[Mono-dev] To split or not to split Mono?
jay at lincore.co.uk
Thu Nov 3 16:46:58 EST 2005
IMO it boils down to what is compariable with ms.net should be in one
every thing else can be split out.
my worry is if the sub parts that replicate ms.net parts are split out
the integration testing of the parts will become harder over time and
will it end up that production environments have sub part versioning
I know that there is a huge overhead but the risk is breaking mono up in
such a way damages its comparibility with ms.net from an end user point
of view and worst makes it even more difficult to explain in the
boardroom of non technical executives that need to say yes.
the other modules dont have the same problem as they are extentions to a
'Baseline' install and in all respects it is easier to deal with them as
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