バージョニング

Workflows実行エンジン、Workflow定義、ブロックがどのようにバージョン管理されるか。

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} ブロックの識別子名前空間を有効に活用するために

  • バグ修正が必要な場合にのみ、特定バージョンのブロックを修正することを推奨します。ブロックへのその他の変更はすべて、新しいバージョンとして扱うべきです

  • ブロックの各バージョンは、新しいモジュールとして提出すべきです（前述のとおり こちら) - たとえ コードの重複を伴っても この特定のケースでは、DRY よりも安定性の方が重要だと考えているからです

  • 同様に、各ブロックはできるだけ独立させることを推奨します。ブロック間で共有されるコードは、意図せず他のブロックを変更し、Workflows の安定性を損なう可能性があるためです