> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/workflows/ja/gaido/developer-guide/versioning.md).

# バージョン管理

Workflows エコシステムのライフサイクルを理解することは重要なテーマです。特にブロック開発者の視点からはなおさらです。適用されるルールは次のとおりです:

* Workflows は〜の一部です `inference` - パッケージ自体は、構成要素のいずれかが変更され、その変更が公開可能になった時点でリリースされます
* Workflows Execution Engine はそのバージョンを宣言します。進め方は次のとおりです:
  * Workflows のコアは、Execution Engine の複数バージョンをホストできます。たとえば、現在の安定版と開発版です
  * 安定版は保守され、新しいバージョンの必要が生じてそれが受け入れられるまで、新機能が追加されます
  * 新バージョンが完全に稼働可能になると、これまでの安定版は非推奨扱いになり始めます。旧バージョンにはバグ修正のみが適用される猶予期間があります（新機能は追加されません）。その後は現状のままとなります。猶予期間中に、ブロック作成者には新バージョンの要件に従ってプラグインをアップグレードするよう呼びかけます
  * コアライブラリは、各メジャーごとに Execution Engine の単一バージョンのみを保守します。つまり、同じメジャー内の機能は破壊的変更を含まず、あるバージョンで作成された Workflow は `1.0.0` そのバージョン下でも完全に動作することを約束します `1.4.3` Execution Engine の
* エコシステムの安定性を長期的に確保するために:
  * 各 Workflow Definition は、互換性のある Execution Engine のバージョンを宣言します。コアライブラリは Execution Engine について単一バージョンしか保守しないため、 `バージョン: 1.1.0` Workflow Definition では、実際には次のバージョンの Execution Engine を要求します `>=1.1.0,<2.0.0`
  * 各ブロックは、その manifest で適切な Execution Engine 互換性を示すべきです。たとえば、ブロックが Execution Engine の機能に依存しており、それが次で導入された場合、 `1.3.7` それは次を指定すべきです `>=1.3.7,<2.0.0` Engine の互換バージョンとして
* Workflows のブロックは任意でバージョン管理できます（Roboflow プラグインではこれを推奨し、適用しています）。
  * ブロックの type identifier について、次の命名規則を提案します: `{plugin_name}/{block_family_name}@v{X}` ブロックの識別子名前空間を有効に活用するために
  * バグ修正が必要な場合にのみ、特定バージョンのブロックを修正することを推奨します。ブロックへのその他の変更はすべて、新しいバージョンとして扱うべきです
  * ブロックの各バージョンは、新しいモジュールとして提出すべきです（前述のとおり [こちら](/workflows/ja/gaido/developer-guide/block-bundling.md)) - たとえ **コードの重複を伴っても** この特定のケースでは、DRY よりも安定性の方が重要だと考えているからです
  * 同様に、各ブロックはできるだけ独立させることを推奨します。ブロック間で共有されるコードは、意図せず他のブロックを変更し、Workflows の安定性を損なう可能性があるためです