リリース

Flux v2.9.0 は機能拡張リリースです。CLI プラグインシステムやセキュリティ機能の充実など複数の新機能を導入する一方、image.toolkit.fluxcd.io/v1beta2 および notification.toolkit.fluxcd.io/v1beta2 の 2 つの API を廃止します。これらの API を使用しているマニフェストがある場合は、アップグレード前に v1 系への移行が必要です。

• breakingimage.toolkit.fluxcd.io/v1beta2 の廃止

  image.toolkit.fluxcd.io/v1beta2 を使用しているマニフェストまたはカスタムリソースは v2.9.0 では動作しません。v1 系 API へ移行してください。

• breakingnotification.toolkit.fluxcd.io/v1beta2 の廃止

  notification.toolkit.fluxcd.io/v1beta2 を使用しているマニフェストまたはカスタムリソースは v2.9.0 では動作しません。v1 系 API へ移行してください。

日本語 準備中pack v0.40.7 is a routine patch: a registry-message text fix, an internal dependency cleanup, and an updated builder suggestion. No breaking or security changes for operators.

日本語 準備中OpenKruise v1.9.0 adds several useful workload features and fixes a pile of stability bugs — including CPU-spike and panic fixes that affect anyone running ImagePullJobs or SidecarSets in production.

• breakingString-formatted maxUnavailable/maxSurge values now rejected by webhook

  Values like maxUnavailable: '5' (a quoted integer string) are now rejected at admission. If your manifests or Helm charts set these as strings instead of integers, the webhook will block them after upgrade. Audit your CloneSet and related workload specs before upgrading to v1.9.0.

• enhancementFix ImagePullJob high CPU before upgrading large clusters

  A cascading reconcile amplification bug was causing ImagePullJob controllers to spike CPU. If you've been seeing unexpected controller-manager CPU pressure, this is likely the cause. Upgrading to v1.9.0 should resolve it — no config changes needed.

• enhancementCloneSet progressDeadlineSeconds and OnDelete strategy now available

  CloneSet now supports progressDeadlineSeconds to surface stalled rollouts, and an OnDelete update strategy for manual upgrade control. Teams doing canary or phased rollouts with CloneSet should evaluate both options — progressDeadlineSeconds in particular fills a gap that previously required external monitoring to detect stuck updates.

日本語 準備中Argo CD 3.4.4 is a patch release focused on stability fixes for health checks, RBAC, diffs, and template rendering. Update if you run multi-namespace setups or use Dex authentication.

• breakingRBAC regression fix for multi-namespace setups

  A prior release introduced a regression in RBAC enforcement for project-scoped resources in multi-namespace architectures. This patch restores correct behavior. If you use project-level RBAC restrictions across multiple namespaces, verify that access controls work as expected after upgrading, particularly around project-scoped resource visibility.

• enhancementHealth check reliability improvement

  The PromotionStrategy health check was incorrectly reporting Progressing after no-op re-hydration, blocking deployments. This is now fixed. If you use PromotionStrategy with ArgoCD, upgrade to avoid stalled health states that require manual intervention to clear.

• enhancementServer-side diff regression resolved

  A recent change broke server-side diffs on new objects, causing errors. This patch restores diff functionality. If you rely on server-side diffs in your deployment pipeline (especially for new resources), apply this update to restore normal diff behavior.

日本語 準備中Argo CD v3.3.12 is a maintenance release fixing sync state tracking, cluster observer locking, configuration parsing, and git repository depth handling—no breaking changes.

• securityDex authentication now handles special characters in passwords

  Dex password parsing previously failed if passwords contained dollar signs, potentially locking users out. If you use Dex for OIDC and recently added or updated passwords with special characters, upgrade to v3.3.12 immediately to restore access. Test Dex login after updating.

• enhancementFix PromotionStrategy stuck state if using Argo Rollouts

  If you run Argo CD with Argo Rollouts and use PromotionStrategy, applications may have remained stuck in Progressing after configuration reloads even when nothing changed. Update to v3.3.12 to resolve this. Check your application health status post-upgrade to confirm recovery.

日本語 準備中v1.52.0 has three breaking changes (discovery API default, immediate stitching removed, BUI union types) alongside significant catalog PostgreSQL performance fixes and a batch of UX and reliability improvements.

• breakingCheck discovery.endpoints and remove immediate stitching config

  Two breaking changes need attention before upgrading. First, if you use `discovery.endpoints` with internal-only string targets, convert them to object form with `target.internal` set to the internal URL and `target.external` set to a browser-reachable URL — otherwise the frontend will try to reach internal addresses directly. Second, remove `catalog.stitchingStrategy.mode: 'immediate'` from your config; it's now a no-op and will log deprecation warnings. Both changes are straightforward config edits.

• breakingMigrate ComboboxProps and SelectProps extensions before upgrading

  `ComboboxProps` and `SelectProps` are now union types. If your codebase has interfaces that extend either type, they will fail to compile — switch them to type intersections. Also audit CSS selectors that target list content as a direct child of `.bui-SelectPopover`, as that structure changed. These are frontend component-layer changes with no runtime fallback.

• enhancementCatalog query performance improvements for PostgreSQL — no action needed, just upgrade

  Several PostgreSQL-specific query planner fixes ship in this release: multi-column statistics on the search table, a dropped redundant index, tuned vacuum thresholds, and a split count/list query. If your catalog list views are slow with large entity counts, this upgrade is worth prioritizing. No config changes needed — the improvements apply automatically via migration. Teams on MySQL/SQLite won't see the same gains.

日本語 準備中flagd core v0.16.0 changes disabled flag evaluation from an error response to a successful resolution with reason=DISABLED, affecting gRPC/OFREP callers and code that inspects evaluation metadata.

• breakingAudit any code that checks errorCode or reason on flag evaluations

  If your code branches on FLAG_DISABLED error codes or checks the reason field from direct gRPC/OFREP responses, it will no longer receive that error path for disabled flags — it'll get a success with reason=DISABLED instead. Search your codebase for FLAG_DISABLED string matches, error-code switch statements, and reason-field conditionals before upgrading. SDK users who only consume the resolved value are unaffected and can upgrade without changes.

• enhancementUse reason=DISABLED for observability and audit logging

  The new behavior is actually cleaner for telemetry. Since disabled flags now resolve successfully, you can distinguish 'flag disabled' from 'evaluation error' in your metrics and logs without special-casing error codes. Update your dashboards and alerting rules to treat reason=DISABLED as an expected, non-error signal rather than filtering it out as noise.

日本語 準備中flagd v0.16.0 changes disabled flag evaluation from an error to a successful resolution with reason=DISABLED, affecting direct gRPC/OFREP callers and code that inspects evaluation metadata.

• breakingAudit error-handling code that checks FLAG_DISABLED or errorCode

  If your application checks the evaluation reason or error code after a flag resolution — whether through direct gRPC calls, OFREP HTTP calls, or Go imports of core/pkg/model — you need to update that logic. FLAG_DISABLED errors will no longer appear; instead expect a successful response with reason=DISABLED. SDK users who only read the resolved value are unaffected, but any monitoring, alerting, or branching logic that keys off FLAG_DISABLED will silently stop triggering. Grep your codebase for FLAG_DISABLED and errorCode checks before upgrading.