改进Drupal的小版本升级体验

Drupal 新的升级模式是一年两次,这让我既对新功能感到兴奋,又担心维护的网站可能会崩溃。 我认为有一些方法可以使升级体验变得更好。


可以改进的东西

我有写过两篇关于新的升级模式的博客文章(12),详细描述了已造成并可能继续造成问题的事情。

这些要点是:

  • 只为最新的次要版本提供安全支持,并且每年会发布两个次要版本(minor version)。
  • 对于贡献模块来说,跟上核心的变化,新功能和新实验性模块,是一个巨大的挑战。

因此:

  • 一个小版本升级可能导致使用贡献(contrib)项目的网站崩溃。
  • Drupal 8 站点需要比以前的主要 Drupal 版本更多的资源来维护。
  • 目前还不清楚是否总是可以维护安全支持所涵盖的工作场所。
  • 这些问题使得 Drupal 8 对于之前的Drupal主要版本中的小型站点所有者不那么有吸引力。


改进观点1:将安全支持覆盖到以前的次要版本中

扩展安全支持以覆盖先前的次要版本将会花更多的时间来解决可能出现的问题。 这也将使维护网站的资源密集度降低,增加对采用 Drupal 8 的兴趣。

当然,这意味着安全团队需要更多的工作,所以我不知道这个想法是否能现实。 但是,当我在Twitter上提到它时,Dries'喜欢'这个想法,所以这让我充满希望!

我在Drupal.org上提出了这个问题的建议,并希望在那里看到讨论。

 

改进观点2:提供一种新方法来了解新核心版本如何影响贡献项目

目前有两种方法可以确定新核心版本是否会破坏您的网站。 最好且唯一完全可靠的方法是在网站上测试新的核心版本。 另一种方法是浏览网站上使用的所有贡献项目的问题队列,查找与新核心版本相关的问题。

能够获得所有已发现可在新核心版本上工作或中断的所有贡献项目的列表将很好。 我相信这个功能在自动更新计划中也很有用,可以确定是否可以进行更新。

这个功能的一个轻量级实现将是以普遍同意的方式标记问题。 例如,如果发现一个贡献模块被 Drupal 8.6.0 所做的更改破坏,则可能会打开一个问题并标记为“8.6.0中断”。 通过这种方式,可以使用“搜索所有项目的问题”页面轻松找到所有被 8.6.0中的更改而破坏的项目。

能够轻松找出哪些贡献项目已被报告在下一个次要版本中被破坏,从而有助于更快修复问题。 这些数据也可以用于了解贡献项目如何使用核心,从而导致破坏。它还将提供有关常见破损如何的有趣统计数据。

备注:本文中的“次要版本”,原文是“mirror version”,是指8.5.x、8.6.x 中的第一个小数点后的这个数字版本。

 

链接 IMPROVING DRUPAL’S MINOR VERSION UPGRADE EXPERIENCE