Contrib.social

Allow (enforce) a grace period before updating to minor releases

Open on Drupal.org →
Created on 20 July 2024, about 2 months ago
Updated 23 July 2024, about 2 months ago

Problem/Motivation

Been thinking about this for a while, but it's not a coincidence this issue was opened during the international crowdstrike outage of 2024 which reminded me to actually post it.

This is also somewhat related to 📌 Is there a clearer way to refer to minor core updates? Active .

Core minor releases come out every six months and are supported for 12 months. Almost every core minor release has one or two regressions - either direct bugs introduced into core, or minor contrib project incompatibilities due to changes to @internal APIs which contrib nonetheless interacts with. Usually both.

Generally we find these issues during rc and the first month or so after a .0 release, and between core patch releases and contrib updates they usually settle down after a month or two. This means that e.g. a site on 10.2.7 will usually have a smoother upgrade path going to 10.3.2 or 10.3.3 than if they update to 10.3.0 a week after it comes out.

On sites I maintain, I will always start a new site on the newest possible core release, whether minor or major, because this means less updates to do later (even if it's one less, still worth it). However for an existing site, I will very happily wait 2-4 months before updating to the next minor release, and more like 3-6+ months for a major release, because by then most issues have shaken themselves out.

Note that Ubuntu has a similar policy. 24.04 was released in April 2024 and the release notes say this:

Support lifespan
Ubuntu 24.04 LTS will be supported for 5 years until June 2029. If you need Long Term Support, we recommend you use Ubuntu 22.04 LTS 4.1k until 24.04.1 is released.

Upgrades
Users of Ubuntu 23.10 will be offered an automatic upgrade to 24.04 soon after the release.
Users of 22.04 LTS however will be offered the automatic upgrade when 24.04.1 LTS is released, which is scheduled for the 15th of August.

https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-not...

I think this applies regardless of site size or the level of site owner technical experience:

If you have a simple site and not much technical experience, then it's worth the extra couple of months wait to avoid having to troubleshoot anything at all.

If you have a complex site and more experience, there is more chance that you have a contrib module installed that will need a small update, or are using a core feature that has a new bug introduced, so it's still worth the extra couple of months wait for the new minor update.

We know both from our own sites that there is non-zero work updating to a minor release, even if it's just testing. And also anecdotally and from usage stats, that a lot of sites get stuck on older releases - and this may partly be because automatic updates isn't in core yet, people running into obscure composer update error messages that they can't decipher etc., but it's also that sometimes people update Drupal, run into problems, then think twice before doing it next time. The more we can mitigate this the better.

Steps to reproduce

Proposed resolution

The most basic idea I can think of is:

1. Always update to the next patch release when it's available - if we don't do this, it'll be hard to do 'instant security updates'.
2. If a release is a minor update, and the version number ends with .0 don't show it by default, or show it with a warning.
3. Add a settings.php (or config) flag to disable this behaviour and show all updates equally.

Remaining tasks

User interface changes

API changes

Data model changes

📌 Task
Status

Active

Version

3.1

Component

Code

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @catch
  • Comment about 2 months ago →
    🇬🇧United Kingdom catch
  • Comment about 2 months ago →
    🇬🇧United Kingdom catch
  • Comment about 2 months ago →
    🇺🇸United States tedbow Ithaca, NY, USA

    @catch something like this seems like a good idea.

    Some questions,

    If a release is a minor update, and the version number ends with .0 don't show it by default, or show it with a warning.

    Does it matter how old the .0 is? Or should assume there will always be a .1 soonish because there will always be something to fix?
    Like what if .0 is 1 month old but also it is the latest in the branch?

    We know both from our own sites that there is non-zero work updating to a minor release, even if it's just testing.

    Regarding the .0 warning is this not the same or almost the same if you were going from say 12.0.7 to 12.1.1 if you happen to miss the 12.1.0 because you use the form and not the background updates?

    Related

    Generally we find these issues during rc and the first month or so after a .0 release, and between core patch releases and contrib updates they usually settle down after a month or two.

    so maybe instead of warning based on .0 should it be basedon minor updates to the site within 1 or 2 months after that minor has been released?
    Like it is updating 12.0.7 to 12.1.4 but 12.1.0 just came out a week ago should still have a warning?

  • Comment about 2 months ago →
    🇺🇸United States tedbow Ithaca, NY, USA

    I would hope we could still do the core alpha version without this. Not that is not a good idea, but there a lot of good ideas and I don't think we can block on all of them. Also if this were a core issue after it were part of core would have many more eyes

    Not saying we should postpone it though, just in the limited time I currently have for AutoUpdates I will probably be focusing more on The Update Framework

  • Comment about 2 months ago →
    🇬🇧United Kingdom catch

    Does it matter how old the .0 is? Or should assume there will always be a .1 soonish because there will always be something to fix?
    Like what if .0 is 1 month old but also it is the latest in the branch?
    ..
    so maybe instead of warning based on .0 should it be basedon minor updates to the site within 1 or 2 months after that minor has been released?
    Like it is updating 12.0.7 to 12.1.4 but 12.1.0 just came out a week ago should still have a warning?

    tbh I thought using wall time might be more difficult that version numbers because it's more things to look at, but I guess if it's in the metadata it's available for this.

    In that case, delaying a minor release update for say two months sounds really good - would handle both of the cases you mentioned - four paper bag releases in one week, vs a .0 release then nothing for months, as well as everything in between.

    This would potentially let us do a longer grace period for major releases too (say three months), although contrib compatibility will often do that anyway.

    Regarding the .0 warning is this not the same or almost the same if you were going from say 12.0.7 to 12.1.1 if you happen to miss the 12.1.0 because you use the form and not the background updates?

    I'm not sure what the question is, but yeah if someone misses the .0 update by accident, then they end up in the same situation as if we make them skip it.

    I would hope we could still do the core alpha version without this.

    Definitely not alpha blocking!

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024