This document describes the high-level roadmap for Mono.
The Mono project started in 2001 as an effort to implement the .NET Framework to Unix. To bring both the new programming model based on the Common Language Infrastructure and C# as well as helping people migrate their existing knowledge and applications to Unix. Mono today supports a wide variety of operating systems, CPUs and a large chunk of the functionality available in the .NET Framework.
At the October 2003 PDC conference a number of new technologies were announced. From the Mono release schedule perspective, we should think about these technologies from their release time standpoint, and the features that must be supported.
This document outlines the roadmap for the Mono project from my perspective: what we can effectively deliver on the dates outlined. Since Mono is a large open source project, things might change and new features can be incorporated into the plan if external sources devote enough attention to those problems.
This is the timeline:
So far Microsoft has published two versions of the .NET Framework: 1.0 and 1.1, the later with incremental updates to the changes in 1.0
The Mono project has been tracking some of the improvements available in those two releases, some of the highlights of our work so far are:
Other components like Windows.Forms, Directory.Services, Enterprise Services and JScript are being developed but are not as mature as the other components but are under development by various people.
Some other smaller and less used components do not have yet a Mono equivalent (System.Management, System.Drawing.Design).
The levels of maturity of Mono fluctuate depending on the development effort we have put into it, and the use we have given to them. For example, the virtual machine and the C# compiler very mature, while less commonly used functionality in Mono like Windows.Forms or VB.NET are still under heavy development.
Our strategy is to release the mature components as Mono 1.0, and have upcoming versions of Mono add extra functionality.
The Mono 1.0 release would include the following components:
Packaging:
Release target: Q2/2004.
Bug fix releases would be done on a monthly basis.
For a detailed list, see the mono-1.0 feature list.
To understand post 1.0 editions of Mono, it is important to put it into perspective with the Microsoft Whidbey product, to be released in 2004.
The new features in the Whidbey release of the .NET Framework include:
The Mono team is developing in parallel some features that wont make it to the 1.0 release in stable form. These will be the foundation for the 1.2 release. The focus of this release is to track the core API for the .NET Framework 1.2, but again, only a subset of the total framework will be available.
Mostly, Mono 1.2 consists of components that were not stable enough for Mono 1.0, but that would be mature at this point, plus the incorporation of some new features from Whidbey. In addition to the Mono 1.0 components, this release will add:
This release will by default provide .NET 1.2 APIs, but compatibility libraries for 1.0 and 1.1 will be distributed in the mono-compat package. The unstable components of Mono will be distributed on the `mono-unstable' package, the libraries in this release will be unsupported.
Release target: Q4/2004.
A refresh update on the Mono 1.2 release containing the missing components from the previous release and complete any under performing pieces. Updates to System.Xml, ASP.NET and Windows.Forms to match the .NET 1.2 API.
Release target: Q2/2005.
Other projects like the debugger, the documentation browser, Java integration through IKVM and Gtk# will remain on their own schedules. This page will be updated to contain that information when it becomes available.
A missing component of Mono is the Code Access Security (CAS). This functionality is not needed in today's Mono as currently Mono is being used to run fully trusted applications, and we are not using it on embedded scenarios where assemblies would have different trust levels.
This is an important component, but requires three major pieces of work:
All of these are major pieces of work, and we currently have no plans to implement any of those. A volunteer effort might be able to help with the runtime requirements and the document, but until those are done, we are unlikely to start doing any work on the actual class library audit and instrumentation.
WinFX is the name given to the new set of libraries that makes up .NET in the Longhorn operating system: the existing .NET set of class libraries, plus the new functionality available in the OS.
WinFX adds things like storage facilities (WinFS), a new versatile communications stack (Indigo) and a new eye-candy packed GUI programming system (Avalon).
Although WinFS, Avalon and Indigo are very exciting components, at this time it is too early to tell when those components will be available for Mono. Open source developers will very likely start work on these, but since they are still far from being officially released, they are not in the radar at this point.
Some technologies are very hard to implement or are being phased out by components in the Longhorn time frame. In some cases, we feel that they are not crucial to the future of the open source desktop.
System.EnterpriseServices and System.Management come to mind, and we are unlikely to put any resources into the task. We would gladly host the code if someone cares to implement it, but they would likely remain unsupported features of Mono.
Mono Developers should read the Mono Hacking Roadmap
Feel free to send your comments or questions the roadmap to miguel@ximian.com
Last Updated: Nov 1st, 2003