.NET エコシステムの LTS とライブラリ更新戦略

1. .NET エコシステムにおける LTS／STS サイクルを押さえる理由

Microsoft は「毎年 11 月にメジャー バージョンを公開し、奇数年を LTS、偶数年を STS に割り当てる」というリズムを明示していますdotnet.microsoft.com。最新のサポート終了日は次のとおりです。

• .NET 6 (LTS) : 2024-11-12 で終了learn.microsoft.com

• .NET 8 (LTS) : 2026-11-10 までサポートlearn.microsoft.com

• .NET 9 (STS) : 2026-05-12 で終了learn.microsoft.com

• .NET 10 (LTS) : 2025 年 6 月時点で Preview 5、正式版は 2025-11 予定learn.microsoft.comdotnet.microsoft.com

この 3 年／18 か月サイクルが ライブラリのバージョン互換性ポリシー を左右します。

---

2. HtmlAgilityPack (HAP) の現在地と対応表

v1.12 系では .NET8 への対応が明示され、旧式の .NET Standard 1.x ターゲットが整理されていますgithub.com。

---

3. ライブラリ開発者の更新戦略

1. ターゲット フレームワークのマトリクス

   • LTS ×2：net8.0 と次期 net10.0 (Preview → RC → GA)

   • 旧 LTS：net6.0 を 2024-11 でビルド対象から外す

   • 幅広い移植性確保：netstandard2.0 を残しておけば .NET Framework 4.8 でも利用可能

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

   • LTS 切り捨てや ABI 互換性を壊す変更は MAJOR を上げる

   • .NET SDK だけ更新し API は不変の場合は PATCH または MINOR

3. リリース ノートの必須情報

   • 対応 .NET バージョン一覧

   • 移行手順（削除 API、置き換え API、ビルド エラー例）

   • サポート終了予定日の明記

4. CI/CD での自動検証

   • GitHub Actions の matrix で複数 TFM を並列ビルド

   • dotnet test --filter "Category!=Slow" を使い高速テストを毎コミット回す

   • Nightly ジョブで .NET 10 Preview もビルドし、破壊的変更を前倒しで検知

---

4. アプリケーション開発者（利用側）の更新ワークフロー

依存関係が多い場合は dotnet-outdated や NuGet Package Explorer で差分を確認し、“脆弱性修正のみ” か “API 変更あり” かを分類すると移行作業が可視化しやすくなります。

---

5. まとめ – 推奨ベストプラクティス

1. LTS を基軸に 3 年単位で計画し、偶数年 STS で先行検証

2. ライブラリ開発者は 最新 LTS + 次期 LTS Preview + netstandard2.0 を最低限サポート

3. 利用側は EOL の 6 か月前までに移行計画を確定し、CI で早期検証

4. HAP は v1.12 系で .NET8 対応済み。次は .NET 10 GA (2025-11) 前に v1.13 以降で公式対応が出る可能性が高い

5. GitHub Releases と Microsoft の公式ライフサイクルページを 定点観測し、Dependabot などで自動化することが “最新リリース情報の追跡” の第一歩です。

この戦略を採ることで、セキュリティ パッチ切れや ABI 破壊による“突然のビルド崩壊”を防ぎつつ、.NET の進化に追随しやすいコードベースを維持できます。