Chapter 2. Notable enhancements
2.1. The plug-in registry can define VS Code extensions preferences
When a VS Code extension have not used environment variables, the user had to set the configuration in the devfile scope. For an extension to modify the configuration of another extension, the user had to create a separate plug-in embedding both extensions. With this release, the user can set default static configurations in the plug-in’s meta.yaml.
- An extension can modify the configuration of another extension.
Example 2.1. Lombok and Java
The Lombok extension is defining configuration for the Java engine.
Additional resources
2.2. Using a new format to specify editors and plug-ins
Before this update, CodeReady Workspaces used the meta.yaml format.
With this update, CodeReady Workspaces is using: * Devfile v2 format to specify editors and plug-ins * an additional che-theia-plugin.yaml fragment to specify plug-ins preferences
This format enables to define: * dependencies between plug-ins * sidecar options * plug-in preferences
Additional resources
2.3. Editors are defined using the devfile v2 specifications.
Editors in che-editors.yaml are defined using the devfile v2 specification, rather than the legacy meta.yaml syntax
Additional resources
2.4. Redesign of the Create Workspace landing page
The landing page is named Create Workspace rather than Get Started Page. The Quick Add tab includes an Import from Git section.
Additional resources
2.5. The per-user namespace strategy is the unique namespace strategy
The per-user namespace strategy is the unique namespace strategy available in CodeReady Workspaces 2.10. Support for other namespace strategies is removed. The CodeReady Workspaces Operator does not allow upgrading installations using a namespace strategy other than per-user.
Additional resources
2.6. Jupyter Notebooks native support through latest Python VS Code extension
Latest python extension includes Jupyter support. This feature is available in CodeReady Workspaces.
Additional resources
2.7. CodeReady Workspaces is Switching to per-user namespace strategy
All namespace strategies except the per-user strategy are unsupported.
This results in:
- Improving security.
- Better administration control over the assigned resource to a user using namespace quotas.
-
Elimination of the need to duplicate sensitive information using Kubernetes secrets, as with the
per-workspace strategy.
Additional resources
2.8. When all workspaces of a user are deleted, delete the PVC to free storage (common storage strategy)
When all workspaces of a user are deleted, delete the PVC to free storage (common storage strategy).
Additional resources
2.9. Use the CodeReady Workspaces ServiceAccount to creates the user namespace
Before this update, when a user didn’t have enough privileges to create a namespace, the workspace start failed. With this update, CodeReady Workspaces always uses the CodeReady Workspaces ServiceAccount to creates the user namespace. An administrator can configure CodeReady Workspaces to create the namespace using the user token.
Additional resources
2.10. Full Support for CodeReady Workspaces on IBM Power Systems
Support for deploying CodeReady Workspaces on OpenShift Container Platform on IBM Power Systems is no longer a Technology Preview feature. CodeReady Workspaces 2.10 is fully supported on IBM Power Systems infrastructure.
Additional resources
