发行注记和已知问题

OpenShift Dev Spaces 在以下 CPU 架构的 OpenShift 4.10-4.12 上运行：

对于 Red Hat OpenShift Dev Spaces 3.5，红帽将为部署、配置和使用产品提供支持。

OpenShift Dev Spaces 和 Eclipse Che 之间的主要区别是：

红帽提供许可、打包和支持。因此，OpenShift Dev Spaces 被视为比上游 Eclipse Che 项目更稳定的产品。

在这个版本中，您可以使用工厂 URL 配置创建新工作区的 Git 远程。remotes 查询参数可以设置为以逗号分隔的 Git remote 列表，每个列表都有可选名称。

在这个版本中，管理员可以使用 CheCluster 自定义资源中的以下参数来设置工作区总数，并为每个用户运行工作区：

例如：

spec:
  devEnvironments:
    maxNumberOfWorkspacesPerUser: 5
    maxNumberOfRunningWorkspacesPerUser: 2

在这个版本中，Git Services 选项卡添加到仪表板中的 User Preferences 页面中。此选项卡列出了您作为已授予访问权限的 Git 提供程序。支持的 Git 供应商有 GitHub (github.com 和 Enterprise)、GitLab (SaaS 和 Server)、Bitbucket （云和服务器）和 Microsoft Azure Repos。

在这个版本中，管理员可以运行 dsc server:deploy --olm-channel=…​，从发行候选(latest)频道或 CI 构建(下一个)频道安装未发布的和不受支持的 OpenShift Dev Spaces 版本。

此增强改进了 Microsoft Visual Studio Code 的 OpenShift Dev Spaces 构建的 GUI - 已停止的工作区的开源。新对话框会通知用户工作区已停止并显示原因。对话框为用户提供两个按钮：返回到仪表板或重启工作区。

在这个版本中，用户可以从托管在 Microsoft Azure Repos 上的公共和私有 Git 存储库启动工作区。Git 存储库维护人员可以在 Microsoft Azure Repos 上托管的 Git 存储库中包括 devfile。管理员可以为 Microsoft Azure DevOps 服务配置 OAuth 2.0。如果不允许管理员配置 OAuth，用户可以使用 Microsoft Azure DevOps Services 令牌作为临时解决方案。在这个版本中，将 Microsoft Azure Repos 添加到 OpenShift Dev Spaces 已支持的 Git 供应商范围内，包括 GitHub (github.com 和 Enterprise)、GitLab (SaaS 和 Server)和 Bitbucket （云和服务器）。

在这个版本中，管理员可以在 CheCluster 自定义资源中将 devEnvironments.storage.pvcStrategy: ephemeral 设置为所有用户的新工作区的默认存储策略。此设置不会影响用户的现有工作区。

在这个版本中，当每个工作区创建持久性卷(PV)时，Dev Workspace Operator 接受 devfile 卷中指定的卷大小。PV 大小由所有 devfile 卷的大小来决定。当每个用户创建 PV 时，卷大小将被忽略。

在这个版本中，管理员可以通过为 spec.devEnvironments.startTimeoutSeconds 输入值在 CheCluster 自定义资源中指定工作空间启动超时。

在这个版本中，管理员可以在 CheCluster 自定义资源中配置 spec.devEnvironments.podSchedulerName 值，将工作区 pod 的默认 OpenShift 调度程序替换为替代调度程序。另一个调度程序应用于所有新启动工作区。

在此次更新之前，从托管在 GitLab 服务器实例上的公共存储库创建工作区没有配置 OAuth 失败。在这个版本中，这个问题已被解决。

在此次更新之前，存在一个影响 Kubernetes 和 OpenShift 组件的 devfile 的问题，这会导致工作空间创建失败。在这个版本中，这个问题已被解决。

在此次更新之前，因为 Dev Workspace Operator 错误配置 Subject Access Review 测试，工作区会失败，并带有类型为 Kubernetes 和 OpenShift 的 devfile。在这个版本中，这个问题已被解决。

在 OpenShift Dev Spaces 3.5 中，在工作区中使用 Eclipse Theia 编辑器已弃用。在当前发行生命周期中，红帽将为 OpenShift Dev Spaces 中的 Eclipse Theia 提供有限的程序错误修复和增强。Eclipse Theia 不再接收 OpenShift Dev Spaces 的增强，并将在以后的版本中从 OpenShift Dev Spaces 中删除。

当升级到 3.6 版本时存在一个已知问题：升级到 devspacesoperator.v3.5.0-0.1682130576.p 的集群需要管理员作为临时解决方案的额外步骤。

或者 ，您可以使用 oc 命令行工具。

目前，在从版本 3.4 升级 OpenShift Dev Spaces 后，用户无法从同一仪表板示例或 Git 存储库 URL 创建多个工作区。

管理员必须在升级前询问用户，将其最新的工作区更改推送到其 Git 存储库，并准备好升级后删除并重新创建工作区。

目前，使用带有 Git-provider 凭证的 Kubernetes Secret 的用户存在一个已知问题。目前，这些用户的 Git 操作的用户名和密码和电子邮件是从 <user> - devspaces 命名空间的 user -profile Secret 中获取的。

目前，Microsoft Visual Studio Code 中的调试器 - 开源无法在 .NET 示例中工作。

目前，如果存储库不包含 devfile 或 v1 devfile，基于 Bitbucket.org-hosted 存储库的新工作区将无法启动。结果是 Failed 用来创建工作区 错误消息。