[Mono-dev] Mono version numbering

[Euan MacInnes]

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: apenwarr at gmail.com> To: meebey at meebey.net> CC: mono-devel-list at lists.ximian.com> Subject: Re: [Mono-dev] Mono version numbering> > On 31/10/2007, Mirco Bauer <meebey at meebey.net> 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> Mono-devel-list at lists.ximian.com> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071101/a3a1c24d/attachment.html