2008-06-22 10:31 | 只看楼主
树型| 收藏| 小 中 大 1

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 (miguel@ximian.com).       
    Posted by Miguel de Icaza on 29 Oct 2007
Sinoprise Network Studio
        ----专注.NET技术