[Mono-dev] Planning: Mono version numbers.
Sharique uddin Ahmed Farooqui
safknw at gmail.com
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
- 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
> 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.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list