Chapter 1. Release notes
Red Hat CodeReady Workspaces is a web-based integrated development environment (IDE). CodeReady Workspaces runs in OpenShift and is well-suited for container-based development.
This section documents the most important features and bug fixes in Red Hat CodeReady Workspaces. For the list of CodeReady Workspaces 2.5 release issues, see the Chapter 3, Known issues section.
To deploy applications to an OpenShift cluster from CodeReady Workspaces, users must log in to the OpenShift cluster from their running workspace using
- Having multiple CodeReady Workspaces deployments on the same cluster is not recommended, and the ability to do so may be removed in a future release.
- For best performance, use block storage for Persistent Volumes used with CodeReady Workspaces.
1.1. About Red Hat CodeReady Workspaces
Red Hat CodeReady Workspaces 2.5 provides an enterprise-level cloud developer workspace server and browser-based IDE. CodeReady Workspaces includes ready-to-use developer stacks for some of the most popular programming languages, frameworks, and Red Hat technologies.
This minor release of Red Hat CodeReady Workspaces is based on Eclipse Che 7.20.1 and offers a number of enhancements and new features, including:
- Improvements to workspace start and overall performance
- OpenShift Connector plug-in 0.2.0
- vscode-yaml plug-in 0.11.1
CodeReady Workspaces 2.5 is available in the Red Hat Container Catalog. Install it on OpenShift Container Platform, starting at version 3.11, by following the instructions in the Installing CodeReady Workspaces on OpenShift Container Platform 3.11 chapter of the Installation Guide.
CodeReady Workspaces 2.5 is available from the OperatorHub in OpenShift 4.4 and beyond. CodeReady Workspaces 2.5 is based on a new Operator that uses the Operator Lifecycle Manager. This makes the CodeReady Workspaces installation flow simpler and doable without leaving the OpenShift Console.
To install CodeReady Workspaces for OpenShift 4.4 or later, get CodeReady Workspaces from the OperatorHub and follow the Installing CodeReady Workspaces on OpenShift 4 from OperatorHub chapter of the Installation Guide.
1.2. Notable enhancements
1.2.1. Support for IBM Power Systems
CodeReady Workspaces can now be deployed as an Operator on OpenShift running on IBM Power Systems using OperatorHub.
IBM Power Systems is supported on:
- OpenShift Container Platform 4.5
- OpenShift Container Platform 4.6
- IBM Power Systems supports restricted environment installations on OpenShift Container Platform 4.6.
1.2.2. Avoid the need to create wildcard certificates
This update brings support for workspaces running on OpenShift that were not allowed to use wildcard TLS certificates.
1.2.3. Support for single-host mode
Single-host mode activates an exposure strategy with a subtype named
gateway that uses a special Pod with reverse-proxy running inside to route requests.
When the single-host strategy is used, all workspaces are deployed to sub-paths of the main CodeReady Workspaces server domain.
In single-host mode, users are not required to use wildcard TLS certificates.
1.2.4. Support for the new OpenShift Container Platform 4.6 Operator index image bundles
OpenShift Container Platform 4.6 introduces a way of installing Operators from an image index bundle. This way of installing Operators is incompatible with OpenShift Container Platform 4.5, which requires the metadata to be formatted and published differently.
CodeReady Workspaces 2.5 on OpenShift Container Platform 4.5 is left available in the older format, known from the previous version of CodeReady Workspaces.
1.3. Other enhancements
1.3.1. OpenShift Connector 0.2.0 update
The 0.2.0 version of OpenShift Connector provides support to
odo CLI 2.0 devfiles.
1.3.2. Node 12 update
plugin-java8-openj9-rhel8images updated from Node 10 to Node 12.
1.4. Support terminations and deprecations
1.4.1. End of Thorntail support and its replacement by Quarkus
As Thorntail is no longer supported, the associated devfile has been removed from CodeReady Workspaces 2.5. Users can use the Quarkus devfile instead to experience performance-tuned Java applications.