[Mono-dev] Planning: Mono version numbers.

Sat May 12 12:07:41 EDT 2007

Sorry for posting again , because it is not posted in mailing list


   - I think it would be better if we develop 3.0 components
   (wpf,wcf,wwf,..) as plugin or addin for mono not as integrated part of it.
   - we should have bi-monthly status report of status.(report must show
   comparative status against MS.net )
   - We should have status page (updated monthly) which targeted to .net
   developers (specially non-mono), which show status API status, with small
   summery, which states which things are not complete. (For example :
   Asp.net- Data controls complete, web parts-50%, Navigaition -control
   complete,....). This will show clear picture about what is complete, how
   much progress has been made.
   - A guide for porting MS .net application to Mono. (Also contain
   other's experience)
   - We should focus more MS .net developer.

-- 
Sharique uddin Ahmed Farooqui
(C++/C# Developer, IT Consultant)
A revolution is about to begin.
A world is about to change.
And you and me are "the initiator".

On 5/11/07, Miguel de Icaza <miguel at ximian.com> wrote:
>
> 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
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070512/e3c8a74f/attachment.html