Dev Spaces 3.31 turns editor choice and workspace policy into live controls
The release removes workspace recreation from IDE changes while DevWorkspace Operator 1.0 gives administrators new network-policy and reconciliation decisions.
Red Hat OpenShift Dev Spaces 3.31 makes two kinds of developer-platform change at once: it lets users change the editor attached to an existing workspace, and it promotes the DevWorkspace Operator to 1.0 with additional controls for network isolation, TLS and metadata reconciliation.
Editor choice stops being a workspace-lifecycle event
The Workspace Details page now exposes an Editor row and a Change Editor dialog. Users can select from the available editors and choose a version where an editor ships more than one. Previously, changing IDEs meant pushing work to Git and creating a second workspace, leaving the old workspace behind.
That changes editor choice from a provisioning decision into a live workspace preference. For platform teams, the practical consequence is fewer duplicate environments and less pressure to encode every IDE decision into a separate golden-path template. It also makes editor testing easier: teams can evaluate a new IDE or version against an existing project without replacing the workspace record.
Dev Spaces 3.31 also adds direct JetBrains links on workspace landing pages, token management in the dashboard, and OAuth refresh-token storage. GitLab users with short-lived OAuth tokens can have expired access tokens renewed when they open the Git Services page rather than restarting the workspace.
DevWorkspace Operator 1.0 adds opt-in isolation
The bundled DevWorkspace Operator reaches version 1.0. Administrators can now enable a NetworkPolicy for each workspace through DevWorkspaceOperatorConfig. The feature is disabled by default, so upgrading does not silently change existing ingress or egress behavior.
That default matters. A platform team that wants per-workspace isolation must make an explicit policy decision and test the required routes to source control, artifact repositories, extension registries and internal services. The operator also reads OpenShift TLS security profiles for its metrics and webhook servers and restarts them when the profile changes. Labels and annotations added to workspace deployments by external admission or policy systems are now preserved during reconciliation instead of being removed.
Administrators have an extension-registry deadline
The internal Open VSX registry can now run an operator-managed CronJob that compares installed extensions with open-vsx.org and publishes newer stable versions. Automatic refresh reduces drift, but it also introduces an external update path that administrators should govern like any other software supply chain.
Red Hat says the deprecated embedded plugin registry will cease to be the default in 3.32 and will be removed in 3.34. Existing installations can keep it as a disabled-by-default fallback during the transition. Teams upgrading to 3.31 should therefore inventory dependencies on the embedded registry and decide whether the internal Open VSX registry may update extensions automatically.
The release still carries operational caveats. JetBrains Toolbox desktop workspaces ignore configured idle timeouts, and SSH-based desktop workflows fail when nested-container capabilities are enabled. Those limits should be included in editor catalogs and cost controls before live editor switching is offered broadly.
sources
- Red Hat OpenShift Dev Spaces 3.31: New features and enhancementsdocs.redhat.com
- Red Hat OpenShift Dev Spaces 3.31: Deprecated featuresdocs.redhat.com
- Red Hat OpenShift Dev Spaces 3.31: Known issuesdocs.redhat.com
comments · 0