Dagster 2026年5月 changelog、1.12 系の複数リリースを確認

Dagster の公式 changelog では、2026年5月に 1.12.9 / 0.28.9 から 1.12.22 / 0.28.22 まで複数のバージョン見出しが確認されています。個別の変更が多数あるため、この記事では5月分の one-page changelog を月次のまとまりとして扱います。

要点

• 公式 changelog は one-page changelog として、Dagster / Dagster+ の version heading を継続的に追加している
• 1.12.9 から 1.12.22 まで、5月の複数バージョンが同じ changelog に並んでいる
• 個別バージョンをばらばらに読むより、5月分の変更としてまとめて確認しやすい
• 詳細な個別変更は changelog 本体を確認し、導入判断では minor / patch の差分と互換性を確認する必要があります

何が変わったのか

Dagster の https://docs.dagster.io/about/changelog では、May 2026 のバージョン見出しとして、1.12.22 / 0.28.22、1.12.21 / 0.28.21、1.12.20 / 0.28.20、1.12.19 / 0.28.19、1.12.14 / 0.28.14、1.12.13 / 0.28.13、1.12.12 / 0.28.12、1.12.11 / 0.28.11、1.12.10 / 0.28.10、1.12.9 / 0.28.9 が並んでいます。公式ページ上はバージョンごとの見出しですが、読者にとっては5月分の変更をまとめて把握するほうが実務に使いやすい内容です。

Dagster のような orchestrator では、patch release でも scheduler、アセット materialization、リソース、連携、UI、Dagster+ control plane などの挙動に影響する可能性があります。特に data platform の運用では、orchestration の小さな変更が backfill、sensor、partition、アセット check、deployment ワークフロー に波及するため、version heading をまとめて追う価値があります。

5月の複数リリースを読むときは、単に最新番号へ上げるかどうかだけではなく、現在のワークロードがどの Dagster 機能に依存しているかを先に確認するのが現実的です。たとえば、partition を多用している環境では backfill や materialization の挙動を、Dagster+ を使っている環境では control plane と OSS ライブラリの組み合わせを、外部システム連携を多く持つ環境では resource や integration 周りの変更を重点的に読みます。小さな patch release でも、本番スケジュール、再実行手順、失敗時の通知、データ品質チェックの扱いが変わる場合があるため、staging で代表的な job run を流してから本番へ広げる進め方が安全です。

対象になりそうなチーム

• Dagster OSS または Dagster+ を運用している data platform team
• 1.12 系へ更新中の analytics engineering / data engineering team
• アセット-based orchestration、partition、backfill、sensor を本番運用しているチーム

実務で確認したいポイント

1. 現在利用中の Dagster / Dagster+ version と May 2026 changelog の差分を確認する
2. scheduler、sensor、アセット checks、backfill に関わる変更がないか重点的に読む
3. patch upgrade でも staging ワークスペース で materialization と job run を検証する
4. Dagster+ 利用時は cloud 側 control plane の変更と OSS ライブラリ version の関係を確認する

どう読むべきか

これは大きな単一発表ではなく、追記型 changelog の5月分を整理する記事です。Dagster を本番のオーケストレーターとして使うチームは、月ごとにバージョン見出しを追い、互換性と運用影響を確認する進め方が安全です。