Improved behavior for update Drupal 8 Core

Improved behavior for Drupal 8 Core updates

At first we want to thank you Tatár Balázs János (European Commission) and Anja Schirwinski (undpaul) for reporting the issue and discussions about the new feature.

Initially, the development of Drop Guard was done for Drupal 7, which has a sequential version numbering system: 7.10 .. 7.20 .. 7.50. If a user uses 7.50 and 7.51 is available he should apply this update and almost certainly this update will be applied without any problems.

Drupal 8 supports several parallel "active branches", right now it is 8.5, 8.6 and 8.7.

Following the logic Drop Guard created and tried to apply any new available update for Drupal 8 Core (of course if the corresponding "update type" was enabled) - even for example from 8.5.3 to 8.7.0. Usually, such updates (to new major version) require manually work with attentive check. But if a user enabled the option "I want Drop Guard to commit updates automatically when they're available" for correspronding update types, then Drop Guard applied such updates automatically.

 

One of those cases happened on previous Wednesday (24th May), when Drupal 8.7.0. was released and all users who enabled "I want Drop Guard to commit updates automatically when they're available" property for "Moderately critically" got new updates up to 8.7.0. That was not expected by our users and actually, it's the wrong behavior, which leads to problems and errors.

 

The big questions is why it happened for the type "Moderately critically" if Drupal 8.7.0 has "normal/not-security" type. To understand that you need to know how Drop Guard detects "security risk level for your update":

The algorithm: Drop Guard gets a current version for Core/module in a user's project, after this it checks all new releases and selects the highest security risk level. This level will be the "security risk level" for the corresponding task.

Because all users use Drupal Core < 8.7.0 and Drupal Core has 8.7.0-rc1 with "Moderately critically" security level risk, therefore Drop Guard marked this update as "Moderately critically" for all users.

 

How to avoid such cases?

To avoid these cases we strongly recommend to use the following:
- "Respect versions constraints" mode
- use correct restrictions in "composer.json" file. Because "Respect versions constraints" will trigger "composer update [PACKAGE]" command. F.e. if you are using Drupal Core 8.6, you need to specify "~8.6.1" restriction (this restriction will only allow updates up to < 8.7.0).

 

Be attentive: if you are using "Respect versions constraints" mode, but your restrictions are very "wide", f.e. (if your restrictions allow to update Drupal Core up to 9.0.0 Drop Guard will do it!). If you are suing very "wide" restrictions better use "Ignore versions constraints" - this mode will trigger "composer require [PACKAGE]=[VERSION]" command and will try to install the same version of core/module which was specified in a task.

 

The improved behavior for Drupal 8 Core updates

We decided improve the logic for Drupal 8 Core update.

 

On the "Site config" page you can see the new property "Core update mode". There are two options available:

1. Provide all new updates. This behavior is like Drop Guard worked before.

2. Provide only minor updates. This is the new setting. It will be selected by default for all existing and new projects. If you select this option Drop Guard will only create update tasks for minor updates (f.e. from 8.6.6 to 8.6.7) of Drupal Core.

Screenshot of site config page

So, since now Drop Guard will create only update tasks for minor updates (f.e. from 8.6.6 to 8.6.7) of Drupal Core (if you are using "provide only minor updates" mode).

 

We hope this new feature will help everyone with Core updates!