[Mono-dev] Planning: Mono version numbers.

[Miguel de Icaza]

Hello folks,

    The versioning of Mono so far has been something along these lines:

	Mono 1.x matches roughly .NET 1.x
	Mono 2.x would roughly match .NET 2.x

    The idea was that people would get a rough idea based on the Mono
version of what they are getting. This is ignoring the fact that there
are technologies that we have no plans on supporting (like enterprise
services, or System.Management that are too Windows-specific).

    But there are problems with the above pattern.  Mono 1.2 (in the
supported areas) is already a superset of .NET 1.1 and it contains
plenty of features only available in 2.0: the C# 2.0 compiler, the v2
runtime, plenty of classes from 2.0 and most recent releases (1.2.4)
have a pretty much complete ASP.NET 2 and System.Xml 2 implementation
with significant 2.0 support in mscorlib and System although not quite
at the 100% state.

    .NET 3.0 turned out to be an add-on on top of 2.0: so the 2.0 APIs
remain unchanged, and a bunch of new libraries were added
(Communication, Infocard, Presentation and Workflow). 

    .NET 3.5 is another set of extensions (at least what we have seen
so far): it builds on the 2.0 core, it only upgrades the compiler and
ships new add-on libraries (System.Core instead of expanding the 2.0
mscorlib.dll).

    Since we have done some work on 3.0 libraries and some work on 3.5
features am not sure that keeping the Mono versioning parity with .NET
versioning parity makes much sense. 

    Things are a bit more complex, because the "roughtly match 2.x"
was actually only a piece of the puzzle, when we talk informally about
Mono 2.0 we talk about:

	* Matching the 2.0 profile (including Windows.Forms)
	* Gtk# upgrades (done)
	* The Compacting GC
	* The VB compiler/runtime (done)
	* Tools for Windows Developers (only partially done) 
	* A chance to change the Mono runtime API.

    We have basically mixed .NET API-matching features, with our
own API features, and with runtime changes.   In addition, the 3.x
work really will come out completely out of sync: 3.5 is a lot simpler
and easier to reach than 3.0 is.  

    So am not sure that our release naming makes much sense as we
stand right now.    We have for one already released various chunks of
what we had originally planned to be 2.0 (Gtk#, the VB compiler) and
it seems fine to keep those running on their own schedules.  

    Maybe we need something like this:

	* Mono A: Estimated 3-4 months of work.
		The core 2.0 done + ASP.NET 2.
		2.0 profile (minus Winforms) becomes officially supported.

	* Mono B: Estimated 6-9 months of work.
		When Windows.Forms 2.0 is complete

	* Mono C: 9+ months. 
		When the Compacting GC is done
		Make the runtime embedding API changes here.

	* Mono D: 9+ months.
		When the new IR/optimization framework is ready

	* Mono E: 6-9 months of work.
		When System.Core and other 3.5 libraries are finished
		maybe we could even split this up in chunks. 

	* Mono F: 
		Support for Silverlight security facilities:
			New security system.
			StackOverflow protection.	
			Complete the Verifier.

    The order of the above releases is not necessarily the one listed
above, and I used letters to avoid discussing the actual release
numbers.   Three of those (C, D and F) are difficult to come up with
an estimate now.

    So what we need is to come up with a new release number scheme for
the above.   

Miguel