2026年5月20日にマージされた「Azure SDK documentation update: eng, use dev feed for set_versions.py」は、Azure SDKのアプリケーションコードや公開APIを変える更新ではありません。要点は、Azure SDK for Javaのリリース自動化で次の -beta.N バージョンを決める際、set_versions.py がMaven CentralではなくAzure ArtifactsのJava dev feedを参照するようになったことです。(GitHub)
そのため、一般のJavaアプリ開発者がすぐに依存関係を書き換える必要は基本的にありません。一方で、Azure SDK for Javaのリリースパイプライン、ドキュメント公開、社内外のフォーク環境、Mavenフィードの許可設定を管理している担当者は、pkgs.dev.azure.com へのアクセス、Azure Artifacts認証、version_client.txt の更新結果を確認すべき更新です。
Azure SDK documentation update: eng, use dev feed for set_versions.pyの概要
今回の変更は、Azure SDK for Javaリポジトリの eng/versioning/set_versions.py に対する小さな修正です。公式PRでは、1ファイルのみが変更され、差分は1行の追加と1行の削除でした。変更対象は get_beta_version_to_use() という関数で、ライブラリのバージョンをインクリメントするときに、既存の X.Y.0-beta.N を調べて次のbeta番号を決める処理です。(GitHub)
変更前は、maven-metadata.xml の取得先がMaven Centralでした。
https://repo1.maven.org/maven2/{groupId}/{artifactId}/maven-metadata.xml変更後は、Azure SDK for Javaのpublic dev feedを参照します。
https://pkgs.dev.azure.com/azure-sdk/public/_packaging/azure-sdk-for-java/maven/v1/{groupId}/{artifactId}/maven-metadata.xmlこの変更により、リリースや開発用フィードへの公開フローと、バージョン番号を判定するスクリプトの参照先がそろいます。PR上のレビュー概要でも、この修正はリポジトリのrelease/dev-feed publishing workflowに合わせるための変更として説明されています。(GitHub)
何が変わったのか
今回のポイントは「beta番号の決め方」ではなく、「beta番号を決めるために参照するメタデータの場所」です。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| 対象ファイル | eng/versioning/set_versions.py | 同じ |
| 対象関数 | get_beta_version_to_use() | 同じ |
| メタデータ取得先 | Maven Central | Azure Artifacts public dev feed |
| 取得するファイル | maven-metadata.xml | 同じ |
| 主な影響 | Maven Central上の公開済み情報を前提にbeta番号を判定 | dev feed上の公開状況を前提にbeta番号を判定 |
| アプリ側のAPI変更 | なし | なし |
get_beta_version_to_use() は、指定された groupId と artifactId の maven-metadata.xml を読み込み、たとえば 1.2.0-beta.1、1.2.0-beta.2 が存在すれば、次に使う番号として beta.3 を返す仕組みです。現在のスクリプトにも、該当するbeta番号の最大値に1を足して返す処理が含まれています。(GitHub)
つまり、バージョニングの基本ルールは変わりません。変わるのは「どこに公開済みとして見えているバージョンを正とするか」です。
なぜdev feedを使うようになったのか
PR本文では、内部のAzure DevOpsリリースパイプラインで失敗通知を受けたこと、ただし修正はリリースパイプライン上の問題であり直接テストしづらいことが説明されています。(GitHub)
Azure SDK for Javaでは、日次ビルドや開発中パッケージをAzure Artifactsのdev feedに公開する運用があります。公式のContributing Guideでも、毎日エンジニアリングシステムがSDKコンポーネントのパッケージを生成し、Azure Artifactsのpublic feedに公開すると説明されています。あわせて、このdaily package feedは一時的な利用を前提とするvolatileなフィードであり、恒久的な依存先として扱うべきではないとも明記されています。(GitHub)
リリースパイプラインでは、パッケージ公開、バージョン更新、ドキュメント更新が段階的に実行されます。Azure SDK for Javaのリリース用テンプレートには、dev feedへの公開、UpdatePackageVersion、PublishDocs、nightly branch向けのドキュメント公開といったジョブが含まれています。(GitHub)
この流れを考えると、Maven Centralだけを見てbeta番号を決めると、リリースパイプライン内で先にdev feedへ公開されたパッケージや、まだMaven Central側に反映されていない状態とずれる可能性があります。今回の更新は、そのずれを避けるために、スクリプトの参照先を実際のリリース・dev feed運用に近づける修正と見てよいでしょう。
影響を受ける対象者
今回のAzure SDK documentation updateは、すべてのAzure SDK利用者に同じ影響を与えるものではありません。確認すべき範囲は、Azure SDK for Javaのリリース自動化に関わっているかどうかで大きく変わります。
| 対象者 | 影響 | 対応の優先度 |
|---|---|---|
| Azure SDK for Javaを通常のMaven依存関係として使うアプリ開発者 | 直接のコード変更は基本的になし | 低 |
| Azure SDK for Javaのbeta版を検証している開発者 | beta番号や公開タイミングの見え方に注意 | 中 |
| Azure SDK for Javaリポジトリのフォークを運用しているチーム | set_versions.py の取り込みとフィード設定確認が必要 | 高 |
| リリースパイプライン管理者 | Azure Artifactsへのアクセス、認証、プロキシ設定を確認 | 高 |
| ドキュメント公開・メタデータ更新担当者 | UpdatePackageVersion やdocs publish後の成果物確認が必要 | 高 |
通常の業務アプリで azure-core や azure-identity などのAzure SDK for Javaパッケージを使っているだけなら、このPRを理由に pom.xml を変更する必要はありません。注意すべきなのは、自分たちのCI/CDでAzure SDK for Javaのリリース補助スクリプトを実行しているケースです。
管理者・開発者が確認すべき設定
pkgs.dev.azure.com への通信が許可されているか
今回の変更後、set_versions.py はMaven CentralではなくAzure Artifactsのpublic dev feedにある maven-metadata.xml を取得します。企業ネットワーク、閉域CI、プロキシ配下のビルドエージェントでは、次のドメインへの通信が許可されているか確認してください。
pkgs.dev.azure.com
dev.azure.comここで注意したいのは、Maven Centralへの通信許可をすぐに削除しないことです。今回の修正は set_versions.py のbeta番号判定に関する参照先変更であり、ビルド全体でMaven Centralや他のリポジトリが不要になったことを意味しません。依存関係解決、プラグイン取得、社内ミラー設定などは別途確認が必要です。
Azure Artifactsの認証設定
Azure SDK for JavaのContributing Guideでは、このリポジトリが依存関係解決にAzure Artifacts feedを使うこと、外部コントリビューターと内部コントリビューターで設定が異なることが説明されています。外部コントリビューター向けには、キャッシュ済みパッケージは匿名で提供される一方、未キャッシュの依存関係では認証が必要になる場合があるとされています。(GitHub)
リリースパイプラインでは、Azure Artifacts認証に MavenAuthenticate@0 を使う箇所もあります。パイプライン側で artifactsFeeds、サービス接続、資格情報、Maven settingsが正しく維持されているか確認しましょう。(GitHub)
特に、次のようなエラーが出た場合は、スクリプトの不具合と決めつける前にフィードアクセスを確認してください。
| 症状 | 確認ポイント |
|---|---|
401 Unauthorized | Azure Artifacts feedへの権限、Maven認証、Azure CLIログイン、サービス接続 |
404 Not Found | 対象artifactのメタデータがdev feedに存在するか、groupId/artifactIdの指定が正しいか |
| プロキシ経由でタイムアウト | CIエージェントのプロキシ設定、許可ドメイン、SSL検査設定 |
| 期待と違うbeta番号になる | dev feed上の既存バージョン、version_client.txt、対象ブランチの状態 |
version_client.txt の更新結果
Azure SDK for Javaでは、eng/versioning/version_client.txt にライブラリごとのdependency versionとcurrent versionを管理する仕組みがあります。Contributing Guideでは、形式は次のように説明されています。(GitHub)
groupId:artifactId;dependency-version;current-versionたとえば、リリース後に次のbetaへ進める場合、set_versions.py はこのファイルや関連するPOM、READMEのバージョン更新に関わります。今回の変更後は、beta番号の判定元がdev feedになるため、次の点を確認してください。
- 対象ライブラリの
groupIdとartifactIdが正しい - dev feed上の
maven-metadata.xmlに既存betaが反映されている version_client.txtのcurrent versionが想定どおりに進んでいる- dependency versionを誤って未公開betaへ寄せていない
- POMやREADME内のバージョン更新タグが期待どおり置換されている
特に、複数パッケージを同じリリースパイプラインで扱う場合、あるパッケージのcurrent versionと別パッケージのdependency versionが意図せずずれることがあります。リリース前レビューでは、差分全体を「ファイルが更新されたか」ではなく「依存関係として使われるバージョンが正しいか」で確認するのが重要です。
移行・展開時の確認手順
フォークしたAzure SDK for Javaリポジトリや、独自のリリース自動化で set_versions.py を使っている場合は、次の順で確認すると安全です。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | PR #49223相当の変更を取り込む | set_versions.py のURLがdev feedに変わっている |
| 2 | CIエージェントからdev feedへアクセスする | maven-metadata.xml を取得できる |
| 3 | 対象artifactでbeta番号を確認する | 既存betaの最大番号 + 1 になっている |
| 4 | version_client.txt の差分を確認する | current/dependency versionの役割が崩れていない |
| 5 | POMとREADMEの更新結果を確認する | 利用者がコピーする依存関係表記が正しい |
| 6 | docs publish系ジョブを確認する | PackageInfoやメタデータ更新が失敗していない |
| 7 | 小さな対象でリリース検証する | beta番号の重複、欠番、公開先のずれがない |
ローカルで完全にリリースパイプラインを再現するのは難しい場合があります。PR本文でも、修正者はリリースパイプライン上の問題であるため直接テストしづらいと述べています。(GitHub) そのため、ローカル実行だけで完了とせず、実際のCI/CD上でメタデータ取得、バージョン更新、公開後の成果物まで確認することが重要です。
具体例：beta番号の判定はどう変わるか
たとえば、あるライブラリの次期バージョンが 1.5.0-beta.N だとします。
dev feed上の maven-metadata.xml に次のバージョンがある場合、
1.5.0-beta.1
1.5.0-beta.2get_beta_version_to_use() は、同じmajor/minor/patchに一致する beta.2 を最大値として見つけ、次に使う番号として 3 を返します。結果として、current versionは 1.5.0-beta.3 のように進みます。
変更前は、この判定にMaven Centralのメタデータを使っていました。変更後はAzure Artifactsのdev feedを使います。そのため、Maven Centralにはまだ見えていないがdev feedには存在するbetaがある場合、変更前後で次に選ばれるbeta番号が変わる可能性があります。
ここで大切なのは、dev feedを「本番利用の依存先」と誤解しないことです。Azure SDK for Javaの公式ガイドでは、daily package feedは一時的な利用を前提とするvolatileなフィードと説明されています。(GitHub) 検証用途やリリース自動化では有用ですが、業務アプリの長期運用では、通常どおり安定版または正式に公開されたbetaを依存関係として管理するのが基本です。
よくある失敗と回避策
Maven Centralの反映だけを見てbeta番号を判断する
今回の変更後、set_versions.py のbeta番号判定はdev feedを参照します。Maven Centralだけを見て「まだ beta.2 がないから次は beta.2 のはず」と判断すると、実際のパイプラインでは beta.3 が選ばれることがあります。
リリース担当者は、Maven Central、dev feed、version_client.txt の3点を分けて確認しましょう。
フィードのアクセス失敗をスクリプトのバージョン不整合と誤認する
maven-metadata.xml を取得できない場合、原因はバージョン不整合ではなく、認証、プロキシ、ネットワーク、フィード権限の可能性があります。特に、Azure Artifacts周りでは 401 Unauthorized が出ることがあります。Contributing Guideでも、401発生時の確認項目としてアクセス権やログイン状態の確認が案内されています。(GitHub)
新規artifactでメタデータが存在しないケースを見落とす
完全に新しいartifactでは、dev feed側にまだ maven-metadata.xml がない場合があります。このとき、単純に「beta.1になるはず」と思い込むのは危険です。スクリプトがどのように例外を出すか、パイプラインがその例外をどう扱うかを確認してください。
PR上のAIレビューコメントでも、urllib.request.urlopen() は非2xxレスポンスで HTTPError を送出するため、ステータスコード確認の分岐だけでは404や401を扱いにくい可能性が指摘されています。(GitHub) 実運用では、失敗ログにHTTPステータスや対象URL、groupId/artifactIdが残るようにしておくと、原因切り分けが速くなります。
docs publishの失敗を後回しにする
この更新は「documentation update」として扱われていますが、単にMarkdownを直す変更ではありません。Azure SDK for Javaのリリーステンプレートでは、パッケージ公開後に UpdatePackageVersion や PublishDocs に相当するジョブが続きます。(GitHub)
つまり、パッケージ公開が成功しても、ドキュメントメタデータや参照ドキュメントの更新で失敗する可能性があります。リリース完了判定では、次の成果物まで確認してください。
- PackageInfoの内容
- docs metadataの更新結果
- README内の依存関係表記
- GitHub Pagesやlearn.microsoft.com向けの参照ドキュメント公開結果
- nightly branch向けのドキュメント更新結果
一般のAzure SDK利用者が取るべき対応
通常のAzure SDK利用者は、今回のPRを理由にすぐ依存関係を変更する必要はありません。確認すべきことは、次の3点に絞れます。
- 自分のアプリがdev feed上のdaily packageに依存していないか
pom.xmlに意図せずalpha版や一時的なフィードのURLを入れていないか- beta版を使っている場合、正式なリリースノートやパッケージ一覧で最新バージョンを確認しているか
Azure SDKのbeta版は、新機能検証やプレビュー機能の確認には便利です。ただし、beta版は将来変更される可能性があります。業務システムで使う場合は、依存しているAPI、リリース予定、GAへの移行計画を事前に確認しましょう。
リリース管理者向けチェックリスト
今回の更新を取り込む担当者は、最後に次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| PRの取り込み | set_versions.py のURLがdev feedに変更済みか |
| ネットワーク | CIエージェントから pkgs.dev.azure.com へ到達できるか |
| 認証 | Azure Artifacts feedへの権限、Maven認証、サービス接続が有効か |
| バージョン判定 | 既存betaをdev feed基準で正しく拾えているか |
| 新規artifact | メタデータ未作成時の失敗ログと対応手順が明確か |
| 依存関係 | current versionとdependency versionの役割が崩れていないか |
| docs更新 | PackageInfo、README、ドキュメントメタデータが期待どおり更新されたか |
| ロールバック | beta番号の誤採番や公開失敗時の再実行手順があるか |
小さな差分に見える更新ほど、リリース自動化では影響範囲を見落としやすいものです。今回の「Azure SDK documentation update: eng, use dev feed for set_versions.py」は、アプリケーションコードの変更ではなく、リリース時に「どの公開済みバージョンを見て次のbeta番号を決めるか」を変える更新です。
開発者は依存関係の利用先を、管理者はCI/CDのフィードアクセスと認証を、リリース担当者は version_client.txt とドキュメント更新結果を確認しましょう。特にフォーク環境や社内ミラーを使っている場合は、dev feedへの到達性を確認してからリリースパイプラインへ展開することが、安全な移行の第一歩です。
コメント