[GH-ISSUE #5733] [Management] Add auto-update track “latest patch of previous minor” (reduce client updates to once per minor) #11928

Open
opened 2026-08-05 01:31:41 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @lorenzbaum on GitHub (Mar 30, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5733

Is your feature request related to a problem? Please describe.
Today the management dashboard allows enabling/disabling auto-updates and choosing either:

  • "latest" (always move to newest release), or
  • a custom pinned SemVer (e.g. 0.55.3).

In environments with many clients, using "latest" can cause frequent updates (every patch). We want a built-in mode to update clients at most once per minor, by targeting the latest patch release of the previous minor.

Example:

  • Latest available is 0.67.1
  • Desired target is 0.66.x where x is the latest patch (e.g. 0.66.4)

This keeps clients one minor behind while still receiving the newest patch fixes for that minor.

Describe the solution you'd like
Add a new auto-update mode selectable in the management dashboard:

  • Latest (current behavior: "latest")
  • Pinned version (current behavior: "0.66.4")
  • Previous minor (latest patch) (new)

Semantics:

  • Determine the latest available release minor (major, minor); for NetBird 0.x.y, treat x as the “minor track”.
  • Compute target minor as (major, minor-1).
  • Select the highest patch in that previous minor as the enforced update target.

If the previous minor cannot be determined (e.g., no releases found for it), fall back to current behavior (either no enforced update or "latest" - maintainers decide).

Describe alternatives you've considered
Alternatively, managers could manually input the desired target from above --> constant work


Additional context:

Implementation notes / code pointers

Client currently supports only "latest" or an exact SemVer string:

  • Client applies the received management setting here:
    • client/internal/engine.gohandleAutoUpdateVersion() calls updateManager.SetVersion(autoUpdateSettings.Version, ...).
  • Client updater token handling:
    • client/internal/updater/manager.goSetVersion() treats "latest" specially; otherwise parses SemVer.
    • handleUpdate() can only target m.update.LatestVersion() or an exact version.

Management server validates AutoUpdateVersion strictly:

  • management/server/http/handlers/accounts/accounts_handler.go only accepts "latest", "disabled", or SemVer; new token will need to be whitelisted.

Version fetching currently exposes only “latest”

  • client/internal/updater/update.go interface only provides LatestVersion().
  • version/update.go fetcher appears to fetch a single latestAvailable version, so selecting “previous minor” likely requires exposing a list of available versions or “latest per minor”.

Acceptance criteria

  • Dashboard UI can select “Previous minor (latest patch)”.
  • Setting is persisted and returned through management APIs like existing modes.
  • Client interprets this mode and updates accordingly (Windows/macOS auto-install mode; Linux download/notify mode).
  • Unit tests cover:
    • correct target selection
    • no-update when already >= target
    • behavior when versions for previous minor aren’t available
Originally created by @lorenzbaum on GitHub (Mar 30, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5733 **Is your feature request related to a problem? Please describe.** Today the management dashboard allows enabling/disabling auto-updates and choosing either: - `"latest"` (always move to newest release), or - a custom pinned SemVer (e.g. `0.55.3`). In environments with many clients, using `"latest"` can cause frequent updates (every patch). We want a built-in mode to update clients **at most once per minor**, by targeting the **latest patch release of the previous minor**. Example: - Latest available is `0.67.1` - Desired target is `0.66.x` where `x` is the latest patch (e.g. `0.66.4`) This keeps clients one minor behind while still receiving the newest patch fixes for that minor. **Describe the solution you'd like** Add a new auto-update mode selectable in the management dashboard: - **Latest** (current behavior: `"latest"`) - **Pinned version** (current behavior: `"0.66.4"`) - **Previous minor (latest patch)** (new) Semantics: - Determine the latest available release minor `(major, minor)`; for NetBird `0.x.y`, treat `x` as the “minor track”. - Compute target minor as `(major, minor-1)`. - Select the highest patch in that previous minor as the enforced update target. If the previous minor cannot be determined (e.g., no releases found for it), fall back to current behavior (either no enforced update or `"latest"` - maintainers decide). **Describe alternatives you've considered** Alternatively, managers could manually input the desired target from above --> constant work --- **Additional context:** ### Implementation notes / code pointers **Client currently supports only `"latest"` or an exact SemVer string**: - Client applies the received management setting here: - `client/internal/engine.go` → `handleAutoUpdateVersion()` calls `updateManager.SetVersion(autoUpdateSettings.Version, ...)`. - Client updater token handling: - `client/internal/updater/manager.go` → `SetVersion()` treats `"latest"` specially; otherwise parses SemVer. - `handleUpdate()` can only target `m.update.LatestVersion()` or an exact version. **Management server validates AutoUpdateVersion strictly**: - `management/server/http/handlers/accounts/accounts_handler.go` only accepts `"latest"`, `"disabled"`, or SemVer; new token will need to be whitelisted. **Version fetching currently exposes only “latest”** - `client/internal/updater/update.go` interface only provides `LatestVersion()`. - `version/update.go` fetcher appears to fetch a single `latestAvailable` version, so selecting “previous minor” likely requires exposing a list of available versions or “latest per minor”. ### Acceptance criteria - Dashboard UI can select “Previous minor (latest patch)”. - Setting is persisted and returned through management APIs like existing modes. - Client interprets this mode and updates accordingly (Windows/macOS auto-install mode; Linux download/notify mode). - Unit tests cover: - correct target selection - no-update when already >= target - behavior when versions for previous minor aren’t available
saavagebueno added the feature-request label 2026-08-05 01:31:41 -04:00
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11928