Mono Versioning

A common problem that I face is explaining to people the current situation of Mono. This is a problem of our own creation when we sketched the major milestones for Mono.

When we originally plotted the course for the Mono Roadmap things looked pretty simple, they were roughly like this:

Mono 1.0:

• Ship the VM 1.0
• Ship the C# 1.0 compiler
• Ship System, Xml, Data, Drawing Web and Web.Services
• Gtk# and friends.

Mono 2.0:

• Upgrade VM to 2.0
• Upgrade compiler to 2.0
• Upgrade libraries to 2.0
• Add Windows.Forms
• Ship Gtk# 2
• Favorite extra stuff (debugger, compacting GC, internal embedding API upgrade)

As you can see, we intended our versioning scheme to track the major Microsoft releases to expedite explanations of what level of APIs Mono supported. So Mono 1.x would be roughly .NET 1.x, Mono 2.x would be roughly .NET 2.x, Mono 3.x would be roughly 3.x and so on.

There is a bit more than just tracking the API, as you can see, there are really two dimensions to what we wanted to call Mono 2.0:

One dimension is the 2.0 compatibility with .NET, and another one has some internal goals of ours. For example, we considered that 2.0 was a good time to break the embedding API for the runtime and also to release the compacting collector.

Complications

There were a few factors that started to complicate our numbering scheme:

• Our Windows.Forms implementation was lagging behind other class libraries (as writing a Winforms control requires much more work than say a Web Control).
• Our desire to implement some major optimizations and improvements in the VM (improved code generation, AOT for 2.x, compacting garbage collection, switch to eglib-based public APIs, change in the embedding API).
• Generics being a requirement for a lot of the 2.0 work that was necessary.
• Microsoft releasing .NET 3.0 which was really just a new set of libraries that just ran on top of 2.0 (we track these in a separate project, called project Olive).
• Microsoft releasing .NET 3.5 which is the actual upgrade to 2.0.
• Some areas would be developed faster than others: sometimes this was due to planning, lack of planning, or big boosts in external contributions (for example, Mainsoft contributed extensively to making ASP.NET 2.0 and ADO.NET 2.0 happen, and they have been shipping their Grasshopper product since ~May).
• We might not support the full API for a given assembly: there might be some features that do not make sense on Linux or features that will never be implemented (like System.Management).

By the time we shipped our Mono 1.2 last year, the problems with the simple versioning numbers started to show. Mono 1.2 included many features from 2.0:

• C# 2.0.
• Generics support in the VM.
• A lot of the 2.0 support in the class libraries. (core, XML, Data and ASP.NET was almost done).
• Support for Windows.Forms 1.0.

Almost a year has passed and we are about to release Mono 1.2.6, six releases after Mono 1.2. Compared to last year's Mono, this upcoming release is a major upgrade, we have since:

• Completed most of the 2.0 support, including:
  • Completed C# 2.0.
  • Completed ASP.NET 2.x (modulo WebParts).
  • Completed ADO.NET 2.x.
  • Most of Windows.Forms 2.0 (about 80% of it at this point).
• Implemented most of C# 3.0 (few tidbits missing).
• Implemented LINQ, and LINQ to XML (.NET 3.5).
• Implemented some other bits from .NET 3.5
• A Visual Basic.NET compiler, and its runtime.
• Added a Silverlight toolchain (.NET 2.1).
• Added COM/XPCOM support to Mono.

From an API perspective, with the exception of Windows.Forms 2.0 we have pretty much completed the 2.0 support (what remains to be done is tracked here for the core and here for winforms).

In addition, some bits from 3.5 are being shipped in this upcoming version.

Since we continue to ship updated versions of Mono every 8 to 10 weeks we have only felt that we needed to update the smallest version number (1.2.6 is our upcoming release) each time.

My concern is that 1.2.xx does not really convey the feature set in Mono and some people get the wrong impression of where Mono is at. This problem is made worse because we have been using the simplified numbering scheme for years.

Just today someone emailed me asking when ASP.NET 2.0 will be released, another person asked about ASP.NET AJAX (supported in SVN, and in the upcoming 1.2.6).

Options

We are looking for a creative solution to this problem.

Without using Mono versions, these are roughly the upcoming milestones:

• 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.
  • Windows.Forms 2.0 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: 12 months of work, Silverlight security features:
  • New security system (done).
  • StackOverflow protection (done).
  • Complete the Verifier.
  • Harden the Mono loader (for Silverlight).
  • Full runtime security audit.

  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.

  Massi advocate a model where for large Mono upgrades (ABI changes, like the GC and the runtime API change) we change the major version.

  This would mean that we could ship a Mono 1.4 at the time that the "core" 2.0 is done; A Mono 1.6 when Winforms 2.0 is done; A Mono 1.8 when the 3.5 APIs are ready; and Mono 2.0 when we do the GC changes. This proposal does not fix the confusion problem with "1.x" though.

  Marek has a slightly modified proposal: when we ship 2.0 minus winforms we call it Mono 1.8; Mono 2.0 includes Winforms, GC, ABI breakage; Mono 2.2 includes new optimization framework;

  Jonathan suggest that we could use the major version number to document what is the version number that we feel we can officially support. 2.0 means "2.0 minus Winforms" with an upcoming 2.2 version with Winforms support and 3.5 thrown in the middle at some point (you will notice that the Olive/3.0 discussion is not part of this decision making).

  Thoughts? email them to the devel group and CC me ([email protected]).