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