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

[Erik LeBel]

hi All,

As an alternative to having possibly several dozen
specialized bundles (which is a possible outcome of
this kind of split), I would suggest something
oriented toward stable and experimental updates:

The stable packages:
Mono-runtime – the portion of mono compiled natively.
Mono-core – stable libraries (compiled once for all
platforms - optionally could be included with the
runtime instead of separately).

And the development package:
Mono-experimental – libraries and tools still under
heavy change.

In this way Mono would not suffer from the packageitis
sometimes seen in other projects, but would protect
users from frequent, unnecessary updates to the stable
packages.

The only compatibility to be maintained between
packages would be at the minor version number (1.2.x
stable to 1.2.x experimental). As components mature,
they get migrated to the stable branch on significant
releases (1.2.x to 1.4.x)

that's my two cents worth as a user, I'm sure others
would find other deployments more useful.

-erik



--- 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
> 



	

	
		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca