バージョニング

セマンティック・バージョニング

Duktapeは、公式リリースの際にセマンティック・バージョニングを採用しています。

• APIと互換性のない変更が行われた場合は、メジャー・バージョンに変更します。
• マイナー・バージョンの変更は、後方互換性のある機能的な変更が行われたときに行われます。
• 後方互換性のあるバグフィックスが行われた場合は、パッチバージョンに変更されます。

このルールが適用される「公開API」には、以下のものが含まれます。

• duktape.orgで文書化されているDuktape APIコール。
• Duktapeオブジェクトと他のECMAScript拡張を含む、ECMAScriptコードから見えるグローバル環境（duktape.orgで文書化されているもの）。

以下のものは、「公開API」のバージョン保証の対象外です。

• experimentalとタグ付けされたDuktape APIコール、およびexperimentalとして文書化されたその他の機能。
• APIマクロによる内部コール。マクロとして実装されたAPIコールはパブリックAPIの一部ですが、マクロが行う内部コールは、たとえそのシンボルの可視性がパブリックであったとしても、パブリックAPIには含まれません。
• APIコールを関数コールからマクロに変更すること(またはその逆)。これらは互換性のある変更とみなされます (ただし、パッチリリースでは行われません)。
• 最新のECMAScriptの仕様に合わせる。Duktapeは、最新のECMAScript仕様（現在はES2016）を追跡しています。最新の仕様に合わせるために必要な後方互換性のない変更は、マイナー・バージョンでも行われることがあります（ただし、バグを修正する必要がある場合を除き、パッチ・バージョンでは行われません）。通常、このような変更は、例えば引数の強制やプロパティの継承の変更など、比較的小さなものです。
• マイナーバージョンでも変更される可能性があると明示的に指摘されている特定の動作、例えば
• バッファオブジェクトのバッキングバッファが、バッファオブジェクトの見かけのサイズより小さい場合の動作。メモリセーフな動作は保証されますが、それ以外の動作はバージョンによって異なる可能性があります。
• Duktapeのコンフィグオプション。互換性のない設定オプションの変更は、パッチリリースでは行われませんが、マイナーリリースでは行われる可能性があります。目標は、サポートされなくなった機能オプションが使われたときに（可能であれば）コンパイル・エラーを発生させ、誤った仮定を修正できるようにすることです。
• Duktape と共に配布される Extras (extras/ ディレクトリ)。

パッチ版がリリースされた場合、以下のことが保証されます。

• APIバイナリ互換性の維持：定数値の変更、関数の型付けの変更、APIコール関数/マクロのステータスの変更はありません。
• バイトコードダンプ・ロードの形式は変更しないので、パッチバージョンのみが異なる旧バージョンからダンプしたバイトコードをロードすることができます。
• ECMAScriptのセマンティックスの修正は、バグフィックスに必要な場合を除き、含まれません。
• 設定オプションが互換性のない形で変更されることはありません。

Duktape リポジトリから作成された開発版ビルドは、公式リリースではなく、厳密なセマンティックバージョン管理には従いません。

実験的な機能

いくつかの新しい機能やAPIコールは実験的とマークされています。これは、マイナーリリースであっても互換性のない方法で変更される可能性があることを意味します。

例えば、有用ではあるが不完全であったり、最適な設計が明らかでないため、設計にコミットする前にフィードバックを収集することが有効であるなどの理由で、機能は実験的とマークされることがあります。通常、ある機能は1つのマイナーリリースで実験的なものとなり、その後、必要な変更を経て、完全にサポートされる機能となります。

バージョンの命名規則

リリースは、(メジャー).(マイナー).(パッチ)の形式を使用します、例えば、1.0.3です。

DUK_VERSIONとDuktape.versionについて

DUK_VERSIONとDuktape.versionは、次のように計算された1つの番号を使ってバージョンを識別します。(major * 10000 + minor * 100 + patch) のように計算された1つの番号を使用し、Duktape リポジトリから作られた開発版ビルド（公式リリースではない）については1つ減算されます。

開発版ビルドの制限に注意してください。

• 例えば、1.3.0リリース以前のmasterからのビルドは、すべて10299として識別されます。
• パッチリリース用の開発版ビルドは、以前のパッチリリースと区別されません: 例えば、1.3.2 より後 1.3.3 より前の開発版ビルドは 10302 と識別されます。

開発版ビルドは実運用に使うべきではありませんが、現在の DUK_VERSION と Duktape.version 番号は、バージョンを比較するのに便利な近似値を提供します：開発版ビルドは、実際のリリースより小さく、以前のリリースより大きい（または同じ）比較をします。

例

以下の表は、バージョンの昇順にいくつかの例を示しています。

Version	DUK_VERSION & Duktape.version	Notes
0.12.0	1200
1.0.0	10000
1.2.99	10299	Development build before 1.3 release.
1.3.0	10300
1.3.2	10302
2.0.0	20000

安定版のメンテナンスについて

長期的なメンテナンス方針はまだありません: 安定版には、少なくとも次の安定版がリリースされ、それに移行する時間ができるまでは、バグフィックス (パッチリリース) が行われます。

互換性のない変更

互換性のない変更の一般的な目標は、古くてサポートされていない機能に依存するアプリケーションのビルドに失敗することです。黙って壊れるよりも、ビルドに失敗する方が望ましいのです。これは、たとえば次のようなことを意味します。

• APIコールのセマンティクスが変更された場合、古いAPIコールは削除され（使用するとビルド失敗の原因になる）、新しいものが追加される。
• 古い機能オプションのサポートが削除された場合、それを使おうとするとビルド失敗の原因となる。

これは厳密なルールではなく、すべてのケースで実現できるわけではありません。