[Mono-dev] Mono version numbering

[Ernesto]

Euan MacInnes wrote:
> I would suggest that, rather than one version, Mono should split up 
> it's packages differently.

I have to agree. If we are talking about a "on size fits all" Mono 
distribution, no version number can be too descriptive.

My guess is that numbering Mono as  either 1.x or 2.x will not solve the 
full problem. If it's labeled "Mono 2.0", people may end up thinking 
they need Mono 1.x to run .NET 1.1 apps (just like they think they need 
Mono 2.x to run .NET 2.0 apps). Or they might try to install Mono 1.x 
and 2.x simultaneously, just like .NET (we are always talking about 
those who don't want to read further than the version number, remember).

This is: either split up Mono runtime into versions 1, 2, etc. or don't 
pay too much attention to version numbers.

I'd like to see the runtime split up, but I guess that's out of the 
question right now. So in the "don't pay too much attention" model, I 
like Marek's proposal (to call it 1.8 when it's "almost 2.0" and 2.0 
when it's really 2.0).

Regards,
Ernesto

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