Skip to content

Version 0.0.24

netbox-proxbox 0.0.24 pairs with proxbox-api 0.0.20, proxmox-sdk 0.0.13, and the backend's REST dependency netbox-sdk 0.0.10. The plugin now declares two NetBox support tiers: a stable tier covering 4.5.8 through 4.6.99, and a new experimental tier covering 4.7.0 through 4.7.99.

Current backend-runtime pairing: netbox-proxbox 0.0.24 <-> proxbox-api 0.0.20 <-> proxmox-sdk 0.0.13 <-> netbox-sdk 0.0.10. This netbox-sdk version is proxbox-api's REST dependency only and does not provide the semantic MCP bridge.

NetBox netbox-proxbox proxbox-api netbox-sdk proxmox-sdk
>=4.5.8 v0.0.24 v0.0.20 v0.0.10 v0.0.13

Experimental NetBox 4.7 support

This release is the first to load and run on NetBox 4.7. It is deliberately shipped as an experimental tier, not a certified one.

NetBox line Tier Status
4.5.8 - 4.6.99 stable certified and CI-gated
4.7.0 - 4.7.99 experimental loads and runs; emits a startup warning
  • What you get. The plugin installs and runs on NetBox 4.7.0 - 4.7.99. The version gate no longer rejects the 4.7 line outright.
  • How it announces itself. Running on an experimental NetBox emits a Django system-check Warning (netbox_proxbox.W001), never an Error, so startup is not blocked. The PLUGINS_CONFIG opt-out silences that maturity notice only; it does not suppress unrelated checks.
  • What was required to get there. View actions are declared as ObjectAction classes rather than the legacy attributes 4.7 removed, from_db() accepts the keyword arguments Django now passes, and the default VM-role seed migration was fixed for ltree-backed NetBox hierarchies. The shared compatibility contract moved to v2.
  • Evidence. The Django test matrix runs v4.7.0-beta1 as a required leg alongside v4.5.8, v4.5.10, v4.6.0, and v4.6.6, so admitting 4.7 is demonstrated to be a pure widening rather than a regression trade.

Known limitations of the experimental tier

  • NetBox 4.7.0-beta1 is a pre-release. Its schema and internals can still drift before GA, so treat 4.7 as evaluation-grade rather than production.
  • The 4.7 leg exercises netbox-proxbox itself. A combined cell covering every companion plugin at once is not possible yet, because released 4.7-capable companion artifacts do not exist.
  • Production deployments should stay on the stable 4.5.8 - 4.6.99 tier.

Compatibility and correctness

  • Certifies NetBox 4.6.6, including the PDM registry override required by its current plugin loading contract.
  • Preserves serializer source identity and corrects storage-node capacity, detail-template, InfluxDB, and sync-state behavior against real Django/NetBox models.
  • Treats an empty configured encryption key as uninitialized and safely creates the key when a primary endpoint secret is first stored.

Release integrity

  • Builds one wheel and one sdist from the exact tagged commit and publishes them to the Gitea Package Registry, which remains the artifact of record.
  • Validates the tag against a strict version pattern before anything is built, and verifies the package is present in the registry after upload.
  • Subscribes to the tag push event only. Gitea emits both create and push for a tag, and subscribing to both would start two immutable uploads for one version.
  • Creates the public GitHub Release for final tags only. A release candidate never produces one, because that event is the sole trigger for the public PyPI upload and an rc must not reach PyPI as though it were final.
  • Builds the public-index distributions from the same tagged commit, so what reaches TestPyPI and PyPI corresponds to the published source rather than a separately fetched copy. Uploads never use --skip-existing, so a failure always advances to a new immutable version rather than silently succeeding.
  • Pushes tags and creates releases only against the single authorised GitHub repository.

Known limitation: publication hardening is deferred

This release publishes through in-repository jobs on the existing shared runners — the same path used by 0.0.23 and every currently published version. The locked release control plane developed during this cycle is not in this release, because the isolated runner fleet it requires does not exist yet.

Specifically, this version does not yet have: credential-free target builds, an exact-byte sealed handoff to a separately administered isolated publisher, supervisor-signed runner attestation, or egress-denied build isolation. Those controls are implemented and reviewed in-tree, and re-land once the isolated runners are provisioned.

This is a deliberate, tracked deferral rather than a regression: 0.0.24 ships at the same publication posture as every release before it.

Upgrade

Deploy proxbox-api 0.0.20 first, then install netbox-proxbox 0.0.24, run the normal NetBox migration and static-collection steps, restart NetBox and its workers, and verify the Proxbox plugin API and synchronization health.