I would suggest that, rather than one version, Mono should split up it's
packages differently.
The main reason for this is simple marketing. Mono needs more .NET activity,
the way to do that is to make it easier for "outsiders" to more quickly grasp
where it's at. To this end, my suggestion here is to separate out a few things:
Firstly, Mono comes as a "kitchen sink" 1.2.5 option at the moment, which
confuses the issue, makes it unrelatable. The C# implementation is closer to
3.0, yet WinForms (part of .NET, not C# itself) isn't quite 2.0 yet, so ideally
what .NET people will grasp faster is:
Mono Frameworks:
Mono.C# 3.0 (includes C# 1.0, 1.1 and 2.0, or not, preferably not, see later)
Mono.VB 2.0
Mono.Boo
Mono.NET 1.1 (Contains Mono.ASP 1.1, Mono.DB 1.1, also installable separately)
Mono.NET 2.0 (Contains Mono.ASP 2.0, Mono.WinForms 1.9.3, Mono.DB 2.0 also
installable separately)
Mono.DB 2.0 (Contains Mono.Oracle, Mono.MySql, Mono.Firebird, etc.. etc..)
Mono 1.2.5 Developer Package (Contains Nunit, Debug, Developer Tools, Help
documentation)
Mono 1.2.5 Hardcore Package (Contains the source code, build files etc...)
Then have the sources available separately for those that need it. It's a basic
renaming, more or less, of what's there already for Linux, except splitting the
mono_core up into more bite-sized, manageable chunks, and then grouping some
existing packages together for those that want to try it, i.e. the Mono.NET
one, and then, especially on Windows, downloading and installing those missing
ones if they ever get used, rather than an uber-installer. My app's in C#, my
users will never need Boo or J# or VB, or ASP.
When there are incremental patches as well, the core package header can
increase as well, i.e. Mono.NET 2.0.1 for example, to indicate that one of the
constituent packages increased.
This is also better for more lightweight environments and applications, i.e.
casual games and Windows CE devices which have download/space restrictions, and
I'd rather not get into custom forks of the mono build to cope with those
scenarios, where download sizes are limited to 5Mb to 10Mb, so a 50Mb download
with 120Mb installation isn't practical, yet small independent companies that
make these games won't want to get into having to provide custom builds of Mono
to do it. The issue here isn't space on the PC, it's the space on the web
portals that sell casual games, and the portal's bandwidth costs, that are the
commercial issues. Generally, their preference is for 10Mb to 20Mb max download
size.
The other reason for doing this route is one of the big barriers to adoption
for games on .NET 2.0 is the size of the .NET 2.0 installation, at 22Mb, it's
14Mb too big, so by making Mono split into smaller more manageable installation
chunks, we're also making it a more viable alternative to .NET on Windows as
well as Linux/MacOSX for low space/small size scenarios. .NET 3.0 itself comes
in at a nice 5Mb installation size, however backwards compatibility with the
bulk of the market (Windows 95/98) has been dropped.
> Date: Wed, 31 Oct 2007 16:14:10 -0400> From: [EMAIL PROTECTED]> To: [EMAIL
> PROTECTED]> CC: [email protected]> Subject: Re: [Mono-dev]
> Mono version numbering> > On 31/10/2007, Mirco Bauer <[EMAIL PROTECTED]>
> wrote:> > > Indeed. For what it's worth, I think either Debian or Ubuntu
> invented> > > some screwy system of installing two versions of the mono
> libraries> > > side by side,> >> > Mono ships 2 different versions of all
> base-class-libraries, one for 1.0> > and one for 2.0, thats nothing Debian
> nor Ubuntu "invented".> > Sorry, my mistake.> > > > Unfortunately, libraries
> linked with gmcs would crash with gmcs2.> >> > Not sure what you exactly
> mean, libraries that reference mscorlib 1.0> > (compiled with mcs) can be
> used with gmcs.> > This is definitely not the case. For example, a simple
> test program> compiled with mcs (v1) in Ubuntu 6.06 will work with the
> mcs-compiled> nunit, but crashes when the same program is compiled with gmcs
> (v2).> It's possible that
this was fixed in a later version of mono.> > > Debian and Ubuntu ships Mono
without modifications (maybe some patches> > for debian integration or bugfixes
takes from SVN), all the different> > versions (1.0 vs 2.0) comes from Mono, as
Mono provides a CLI 1.0/1.1> > and 2.0 runtime.> > This is perhaps the main
source of my confusion: there are 2.0 version> numbers already floating around
in the runtime distribution.> > Have fun,> > Avery>
_______________________________________________> Mono-devel-list mailing list>
[email protected]>
http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________
Mono-devel-list mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
