LSBロードマップ

はじめに

LSBは、各種のLinuxディストリビューション間の「最大公約数」を提供すること、すなわちソフトウエア開発会社（ISV）がLinuxプラット フォーム上のソフトウエアの作成または移植のための単一の開発目標を提供することを目的としています。ここで、「Linuxプラットフォーム」とは、アプ リケーションが動作しなければならないディストリビューションの候補（かつISVによって異なる可能性のある）のことです。

有効な最大共通項としての役割を果たすには、LSBのバージョンからディストリビューションへおよびその逆へのマッピングが容易でなければなりません。ま た、アプリケーションがLSBのあるバージョンをターゲットとしたとき、そのバージョンだけではなく、将来のバージョンでも動作することが保証されている 必要があります。すなわち、LSB 3.0をターゲットとしたアプリケーションは、LSB 3.0、3.1、3.2、4.0準拠のディストリビューション上でも動作することが保証されます。

このような「わかりやすい対応」の要件を満たすために、LSBの各メジャー・バージョンは、エンタープライズ・ディストリビューションのメジャー・バー ジョン、すなわち「世代」と対応しています。したがって、たとえば、LSB 3.xは現行の世代（Red Hat Enterprise Linux ４、SUSE Linux Enterprise ９など）、LSB 4.xは次の世代（RHEL ５、SLE １０など）に、それぞれ対応しています。アプリケーション互換性の要件を満足するために、LSBバージョン3.0以降は、メジャー・バージョンとマイ ナー・バージョンの両方とも、前のバージョンと厳密な後方互換性を持っています。

後方互換性

このような後方互換性を達成するため、LSB標準においては、後続のLSB版は仕様の追加のみ、言葉を換えると、インターフェースは追加されるのみで、急に削除されることはないということです。LSBのポリシーに、インターフェース削除のメカニズムを有していますが、本当に削除されるのは、そのインターフェースに「削除予定(deprecated)」と表示される状態を少なくともLSBの版数で３版を経た後、あるいは、およそ６年を経た後としています。

LSBでは、LSB仕様からあるインターフェースが削除されるときにアプリケーション開発者が対応する十分な時間をとれるようなインターフェース削除ポリシーを定めています。このポリシーのために、開発者はLSB仕様に信頼を置くことができ、また、変更に対する計画的な対応が可能となります。

インターフェースの削除は次のようなプロセスを経て行われます。 あるインターフェースはLSBワークグループによって削除することが決定されます。 LSB仕様の次回改版時に「削除予定(deprecated)」と表示されます。 削除予定となってから3つ目のメジャー版の最後までインターフェースを残されます。 LSB仕様書の中で「削除(deleted)」と表示され、標準からなくなります。LSBデータデース上では残っています。

ハイレベルなLSBロードマップは次のようになっています。

おおまかなLSB4.0のロードマップは以下の通りです。より技術的な最新情報は以下のProjectPlaan40のサイトをご参照ください。

http://www.linuxfoundation.org/en/ProjectPlan40

LSB 4.0（2008年） スケジュール

2008年4月14日　 計画の確定

2008年8月1日 機能確定 2008年10月3日 ベータ1版

2008年10月31日 RC1

2008年11月11日 LSB4.0

機能の計画

* glibc 2.4

* LSB 3.xとのバイナリ互換性

* SDK使い易さ

* GtK・Cairoの新版

* Java

* LSB準拠のRPMpパッケージを容易に作製できるようにする

* 暗号化API

過去のロードマップ 過去の記録として参考まで。

http://www.linuxfoundation.org/en/Lsb32Roadmap