Comment by scottfalconer
1 day ago
> which was the last major version that supported upgrading in place from the previous versions
This isn't correct. Yes it was true from Drupal 7 to 8, but one of the primary goals of that change was so that every major version after could have seamless in-place upgrades - which they have. Yes there's deprecated code etc. that you might run into in contrib. or custom modules, but the site upgrades themselves are easier than ever.
I'm aware that the modern Drupal supports in-place upgrades for the most part, though white screen of death reports are still pretty common. My point was that there was a split from classic Drupal to modern 'you have to use the command line and should know how to code' Drupal in terms of upgrades from the 7 to 8 split-off.
From all my reading in the Drupal subreddit, modern Drupal isn't especially useful for real world scenarios without a bunch of contributed modules and stuff... hence Drupal CMS. Additionally, folks were recommending not using Drupal 11 until it had been out for well more than a year due to the sad state of contributed module upgrades. I'd wager this is due to the much smaller Drupal community than the version 7 highs.
> modern 'you have to use the command line and should know how to code' Drupal
I get needing to have command line skills for a web framework upgrade (doesn't seem like an unreasonable expectation to me), but why on earth would an upgrade require writing your own code?