このドキュメントでは、Monoのハイレベル ロードマップを示します。
Monoプロジェクトは、2001年に、.NET FrameworkをUnixで実装するという挑戦として始められました。共通言語ランタイムおよびC#に基づく、新しいプログラミングモデルを実現するため、また人びとが知識とアプリケーションをUnixに移行させる助けとするためでもあります。こんにちでは、Monoは幅広いオペレーティング システム、CPUそして.NET Frameworkで利用できる幅広い機能をサポートしています。
2003年のPDCカンファレンスにおいて、数多くの新しい技術がアナウンスされました。Monoのリリース スケジュールの見通しとして、私たちはこれらの技術についても、サポートされなければならない機能、彼らのリリース時期をもとに考えなければなりません。
このドキュメントでは、Monoプロジェクトのロードマップを、わたしの視点から概説するものです。Monoは巨大なオープンソースプロジェクトになってしまったので、変更されることもありえますし、この問題に注目して、外部ソースから新しい機能が計画に追加されることもありえます。
これがタイムラインになります:
現時点で、Microsoftは2つのバージョンの.NET Framewoekを出しています。バージョン1.0と1.1で、後者は1.0の変更の累積的なアップデートです。
Monoプロジェクトはこれらの2つのリリースで利用可能になった改善点のいくつかを追っています。私たちの成果のハイライトを、現時点でいくつか挙げると:
Windowsフォーム、ディレクトリ サービス、エンタープライズ サービス、JScriptは、開発はされていますが、成熟しているとはいえません。ただ、これらはさまざまな人びとによって開発が進められています。
より小さい、またほとんど使用されていないコンポーネントは、Monoでは同様にはサポートされません (System.Management, System.Drawing.Design)。
Monoの完成度は、私たちが注力できる開発の度合いと、私たちが提供できる使用経験に依存するものです。たとえば、仮想マシンとC#コンパイラは非常に完成度が高く、逆にWindows.FormsやVB.NETのように一般にあまり使用されないものについては、まだヘヴィな開発途上にあります。
私たちの計画は、成熟したコンポーネントをMono 1.0としてリリースし、Monoのそれ以降のバージョンで、拡張機能を提供しようというものです。
Mono 1.0 リリースには、以下のコンポーネントが含まれることになるでしょう:
パッケージ:
リリース目標: 2004年第2四半期
バグフィックス リリースは月単位で行われる予定です。
より詳細なリストについては、mono-1.0 機能リストを参照してください。
Monoの1.0 エディションを理解するには、2004年にリリースされるはずのMicrosoft Whidbeyプロダクトの見通しと比較することです。
.NET FrameworkのWhidbeyリリースに含まれる新機能は:
Monoチームでは、1.0リリースを安定した形でリリースさせないような、新しい機能も、平行して開発していきます。それらは1.2リリースの基盤となることでしょう。このリリースの焦点は、.NET Framework 1.2のAPIを追いかけることにあります。ただし、繰り返しますが、フレームワーク全体のサブセットのみが利用可能になります。
基本的に、Mono 1.2 はMono 1.0ではまだ安定していないがその頃には成熟してきているであろうコンポーネントと、Whidbeyにおけるいくつかの新機能との組み合わせで構成されます。Mono 1.0コンポーネントに加え、このリリースには次のものが含まれることになります:
このリリースはデフォルトで.NET 1.2 APIを提供しますが、ただしmono-compatパッケージとして、1.0および1.1互換のライブラリにもなることでしょう。Monoの不安定版コンポーネントはmono-unstableパッケージとして配布され、そのリリースのライブラリはサポートされないことになるでしょう。
リリース目標: 2004年第4四半期
その前のリリースで不足しているコンポーネントで作業中だったものを含むMono 1.2のリフレッシュ アップデートであり、System.Xml, ASP.NET, Windows.Formsを.NET 1.2 APIにマッチさせるためのアップデートであります。
リリース目標: 2005年第2四半期
デバッガ、ドキュメンテーション ブラウザ、IKVMを使用したJava統合、Gtk#などのプロジェクトは、それらのスケジュールに合わせて続行します。このページには、それらが利用可能になったら、その情報も合わせて更新します。
Monoで不足しているコンポーネントは、コードアクセスセキュリティ(CAS)です。今のところ、Monoはfully-trustedのアプリケーションを実行するために用いられているので、この機能は現時点でのMonoでは必要とされていませんし、アセンブリが別々の信頼レベルを持っているかもしれないような、埋め込み(embedded)のシナリオでは使用していないのです。
これは重要なコンポーネントですが、3つの主要な作業が必要となります:
これらは全て作業のメジャー ピースであり、私たちは今のところこれらのいずれも実装する予定がありません。ランタイム要件とドキュメントでは、ボランティアで協力していただくことが可能です。ただし、それらがなされたとしても、実際のクラスライブラリの検査測定を行うとは思えません。
WinFX はLonghornオペレーティング システムにいて .NETを作り上げる、新しいライブラリのセットの名称です。既存の.NETクラスライブラリのセット、プラス、このOSで新しく利用可能になる新機能、ということになります。
WinFX は、ストレージ機能のようなもの(WinFS)、新しい通信スタック(Indigo)、目玉である新しいpacked GUIプログラミングシステム(Avalon)を追加します。
WinFS, Avalon そして Indigo は非常におもしろいコンポーネントですが、現時点ではこれらのコンポーネントをMonoで利用可能にするには早すぎます。オープンソース開発者は、これらの作業をすぐにでも始めたいところでしょうが、それらはまだまだ公式にリリースされたものではなく、まだ目標として設定できません。
いくつかの技術は、実装するのが非常に難しいものであり、あるいはLonghornに含まれるコンポーネントにおいて廃止されるものもあります。将来のオープンソース デスクトップにおいて、私たちはそれらが致命的な問題ではないと考える場合もあるでしょう。
System.EnterpriseServices と System.Management が、すぐに思いつく事例ですが、私たちはこのタスクにリソースを割り当てたくはありません。もし誰かがそれらの実装の面倒を見てくれるというのであれば、私たちは喜んでコードをホストしますが、それらはMonoの機能としてはサポートされない状態のままになることでしょう。
Mono 開発者は、Mono Hacking Roadmapも読んでおくべきです。
このロードマップに関するあなたのコメントや質問は、どうぞ miguel@ximian.comまで送ってください。（訳注: 翻訳に関してはatsushi@ximian.comまでどうぞ）。
最終更新日: 2003年11月1日
翻訳最終更新日: 2003年12月6日