Drupal 11 readiness meeting / 15 July 2024 [#3463160]

Hello and welcome to this Drupal 11 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 11 upgrade of their sites are also welcome.
➤ Happens every Monday at 20:00 CEST (currently 18:00 UTC).
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3459916`
➤ *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

0️⃣ Who is here today? Comment in the thread below to introduce yourself.

Björn Brala (bbrala)	Bjorn, facilitator for today 🙂
xjm	:wave: Just got back from lunch
dww	Derek :wave:
catch	:wave:
kimb0	Kim :wave::skin-tone-2:
VladimirAus	Vladimir :wave:
quietone	Hi
Kristen Pol (she/her)	Kristen :wave: California

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.

hestenet (he/him)	topic: Shall we start an issue for the Drupal 11 release landing page?
VladimirAus	Drupal 11 documentation. Should we start separate guides for each major version or keep current ones up to date?

2️⃣ Celebrations :tada:

Björn Brala (bbrala)	#3449815: [meta] Requirements for tagging 11.0.0-rc1 Drupal 11.0.0.-rc1 has been released!
VladimirAus	D11 release: https://www.drupal.org/project/user_default_page/releases/9.0.2

3️⃣ #3449815: [meta] Requirements for tagging 11.0.0-rc1 With D10 keeping support for longer, messaging around upgrades will become broken when new minors get released (via @xjm) (edited)

Björn Brala (bbrala)	Looking at the meta issues link with all alpha/beta (and adding rc) it seems there is nothing that needs doing right now?https://www.drupal.org/project/issues/search/drupal?project_issue_follow...…]gs_op=%3D&issue_tags=alpha+target%2C+beta+target%2C+rc+target
xjm	This https://drupal.slack.com/archives/C7QJNEY3E/p1720774839332879 came up in committer Slack. Could use its own thread. TLDR, Drupal has no protections about downgrading your API from 10.4.0 to 11.0.0 or whatever, so we may need (a) an update hook as a hotfix/hack to tell you to go to 10.4+ or 11.1+ instead, and (b) in the longer term, core logic/APIs and update module fixes to steer people away from a bad upgrade path.
dww	I thought this was impossible, but I was working on a 9.5.x site that needs an update, and noticed the available updates report is recommending 11.0.0-rc1. I was under the impression we never recommended anything other than official releases without “extra”.
dww	Not sure if this is a bug in update.module or if the core committers prematurely marked the 11.0.x series as “recommended” on the project page. Or both. :sweat_smile:
xjm	checks 11.x metadata on 3060
dww	I’ve been in family crisis hell for a few weeks, and am only on my phone right now. I should search the update.module issues
Björn Brala (bbrala)	Hmm, ok we can move to another thread.
dww	Hey, whoops, sorry. Didn’t mean to hijack
Björn Brala (bbrala)	no dww, no worries, i ment xjm her link
xjm	For now it's the only thing in this thread but we can leave space for other topics later 🙂
Björn Brala (bbrala)	ill repurpose this.
xjm	@Björn Brala (bbrala) I'll post the separate thread 🙂
xjm	@Björn Brala (bbrala) Oh you did, ty
xjm	@dww 3060 metadata about the release is already correct (11.x is not recommended yet):
dww	Very weird. Probably an update.module bug. Thanks for checking.
dww	Perhaps an existing bug that’s been open for 12 years or something. :joy: I’ll have to search later b
xjm	There is a longstanding issue about the module update page downgrading modules for you even without the divergent release numbering -- separate page, similar problem
xjm	https://www.drupal.org/project/drupal/issues/850846 that one
xjm	That page is being deprecated in favor of AU, but the API-level problem is probably still there
xjm	Of course core never allowed upgrading core until AU
dww	And I’m talking about Available updates report, not the updater form.
xjm	But you can still do the updates with a composer command also
Björn Brala (bbrala)	AU updates using composer right? And since composer is used everywhere now (right?) its an UI bug only really isnt it :x
dww	Available updates report has always been UI to tell you what to do by other means. So it’s still a bug, regardless
xjm	@Björn Brala (bbrala) Right, like composer will also downgrade things in terms of the actual release number if you ask. We just need to dissuade people from downgrading in as many places as possible, including update hooks, the update UI, etc.
Björn Brala (bbrala)	valid point yes
xjm	So there are existing problems, but also a new problem in that for the first time 10.4 actually will have APIs that 11.0 doesn't, which previously would have broken the backport policy.
xjm	So we have high-level issues to improve the user journey and fix other bugs, and a specific problem of what to do about this new version numbering thing
dww	Oh yikes. That reality hadn’t fully settled in. That’s definitely going to bump against many assumptions in update module logic.
xjm	Yep exactly
xjm	Dangling thread on a sweater
Björn Brala (bbrala)	hmm
dww	I sure wish core actually followed semver. :joy:
xjm	@dww This is still following semver
xjm	I checked 🙂
xjm	It's just a more complicated implementation thereof
dww	That’s what update manager was implemented to assume, before semver was ever formalized. :sweat_smile:
xjm	What we're doing is allowed by the spec, but breaks old core assumptions
xjm	https://semver.org/ for reference. There's nothing there that says 10.4 MUST NOT include API additions/deprecations that are not in 11.0.
xjm	The issue is more https://www.drupal.org/about/core/policies/core-change-policies/backport... is also a hardcoded assumption
xjm	Or at least an implication
xjm	Well hmm something weird has happened to the content of that page; it's actually missing the original policy? (edited)
xjm	x-posted the issue about that page to committer Slack
xjm	The core policy I mean is that "old versions never get features/APIs not already present in newer versions" which is now modified by "except that 11.1 and 10.4 have equivalent APIs and 10.4 includes additions not present in 11.0". (edited)
xjm	FWIW contrib could also always do this; it's just different from what we've expected from core especially under the new branching practice since 8.0
	Some modules worked around it, like views released 6.x-3x and 7.x-3.x together; there was never a 7.x-2.x. So if we were historical views, we would have skipped straight to 11.3 instead of having an 11.0. But that is arcane Drupal logic, not actual semver. (edited)
catch	So if we add an update path to 10.4 and 11.0 with the new update APIs it will cause a requirements error when you update to 11.0 and tell you to update to 11.1.Another thing we can do is release 11.1 a week before 10.4 or something.Something to maybe try to check is if you're on 10.4 and both 11.1 and 11.0 are available, do we only show 11.1 or both? (edited)
xjm	Sounds like more having to fake update module data for manual testing which is something that we almost need to provide a handbook page for...
xjm	Basically have to hack core to do what update module tests do
catch	If update module does only show the newer release, that'd be good. Then we're only dealing with people who independently think it's a good idea to go to 11.0 first and that composer won't stop them. Is the update hook enough for that? (edited)
xjm	I think update module shows everything that's not insecure:#2865920: Add tests for when a single supported branch has 2 security updates that are both not insecure (the issue summary update and retitle obscure the earlier scope of that...)
quietone	tedbow commented in 2021 that the update module no longer shows everything that's not secure.
quietone	And non stable releases are now listed as 'Also available', not recommended. (edited)
xjm	But dww seemed to indicate that that was actually not the case. The thing that was fixed on the previous issue was just that we no longer show insecure security releases. Nothing else was changed.
quietone	tedbow tested on 9.2 and thought the problem was fixed. And I have not been able to reproduce it on 10 or 11
xjm	AFAIK, it's related to how many releases are marked insecure or not.
xjm	So if releases are marked insecure regularly across forward branches, it won't be noticeable.
xjm	Thus mitigated 🙂
xjm	But this still doesn't address the relationship between 10.4 and 11.1 when both are stable
quietone	Yes, the 10.4 update path needs attention and I mentioned a way forward on the other thread.
xjm	Sorry which other thread?
quietone	This https://drupal.slack.com/archives/C7QJNEY3E/p1720774839332879 came up in
xjm	Oh ah, maybe I missed some comments
	For posterity/meeting record, @quietone wrote:Yes, some tests in the update module need to be added for equivalent updates. My first thought is at the end, after update module has calculated the recommended update, to then check for equivalent updates and adjust accordingly.
	I believe core would need new logic or metadata to "check for equivalent updates", since schema version ≠ release installed (edited)
dww	FWIW, the original bug I was worried about is seen in this screenshot of a local 9.5.11 test site... (edited)
dww	But yeah, all this other stuff about update module on 10.4.0 having to know that 11.0.x isn't a good target and people will need to go straight to 11.1.x is probably a much bigger problem and will require much bigger changes to update.module.
dww	Based on my understanding of how the update.compare.inc logic works, 9.5.11 should not say "Recommended version: 11.0.0-rc1" since that release still has "extra", i.e. it's alpha/beta/rc, not a "stable" release. I was expecting it to tell me that 10.3.1 was "recommended", just like node.3060 recommends... (edited)
catch	Do (did) we need to uncheck 'supported' for 11.0 prior to the stable release?
xjm	Well we need it to be supported to get the special upcoming branch thingy on the project node
xjm	Might be an issue of logic mismatch between d.o and update.module
dww	Either the logic in update.module changed at some point, or I'm mis-remembering, or it's just a plain old bug. I don't think y'all did anything wrong on the project node. There was once logic that prevented recommending releases with "extra". Either that's now gone, or it's been broken by other changes.
dww	I should "just" try to debug this 9.5.11 site and see what it's seeing and thinking and why.
quietone	If I change the version in Drupal.php to 9.5.11 the updates are
xjm	Yah, so I would argue that the UX of that still needs a lot of work.
xjm	Maybe not "wall of terror", but still too many choices with too little advice for the user
xjm	But that ss reminded me that I forgot about a second issue that was fixed besides making releases support an insecure status, so another mitigation I'd forgotten about
quietone	An intermediate step for the 10.4/11.1 problem could be to add a sentence to the page for sites on 10.4+
xjm	People don't read sentences 🙂
	They look at links and buttons, and there should only be 1-2 action choices, not 3
quietone	I just read your last sentence
dww	That's cuz this is Slack, not a UI. :laughing:
xjm	lol sorry, I mean that users tend to skip over paragraphs of text in the UI and focus on available actions
quietone	@dww well said.
catch	It's odd that dww's real site and quietone's test sites get different results.
quietone	There have been several fixes recently to the update.module that change what is displayed
dww	quietone's site is 10.x.y pretending to be 9.5.11. Mine is actually 9.5.11.
quietone	Yes
dww	So it's entirely possible I'm looking at a bug that's already been fixed. That's what I'm trying to debug now.
xjm	Ahh nice, maybe some of the other issues that I noticed back in 2018 but was unaware of as bugfixes
xjm	Or I mean that I was unaware of fixes having been committed. I'm much less aware of all the changes going into core than I was when I was full-time salaried in my role.
quietone	It suits me working on these types of update module issues. It is unfortunate that the code is 'dated' and the tests are a pain.
dww	Drupal was allergic to OOP when I wrote all the update.module code. :sad-panda: It had to be ArrayPI to even be considered "valid" back then. :cry:
xjm	Yah, and it was a part of core that didn't get rearchitected in D8, because it wasn't entity-based and it worked "enough" for 8.x+
xjm	Improving it in general is really valuable and also helps peripherally with AU
dww	Plus, I was way too burned out in that transition to 8.x to do a massive rewrite (for free) at that time, and it's limped along ever since.
xjm	@dww Definitely not on the subsystem maintainer to rewrite things for D8! things got rewritten with hundreds of contributors, or thousands
dww	Anyway, we're getting off topic again. :sweat_smile:
dww	Semi related, I'm going through the monster update_calculate_project_update_status() (comparing the actual 9.5.11 site to 10.3.x for now), and both branches have this nasty bug, waiting to bite us: if (!empty($project_data['status'])) { // We already know the status for this project, so there's nothing else to // compute. Record the project status into $project_data and we're done. $project_data['project_status'] = $available['project_status']; return; }
dww	git blame points here:commit 0c2dbb728d9fa2f09504c30f77e082660e0f872d Author: Angie Byron Date: Tue Dec 29 06:53:04 2009 +0000 #669626 by dww: Reduce RAM bloat: split update status logic into a per-project helper and only s ave available release info we care about.Mea culpa. :laughing:
dww	Meanwhile, yeah, looks like the the 9.5.11 problem is due to the whole "supported_branches" thing. And that logic looks unchanged from 9.5.x to 10.3.x. A few problems:The comments don't really match the logic. The comment says "The logic is such that we don't ignore "supported" branches with no stable releases.(edited)
	Sorry, the comment says: // We know the current release is unsupported since it is not in // 'supported_branches' list. We should use the next valid supported // branch for the target major version.But the logic doesn't implement "next valid supported branch", and instead always uses "the newest supported branch"
xjm	Ahh right, d.o metadata says D9 is unsupported, so we would need to fake/alter that metadata to test with two actually supported major versions
dww	Furthermore, none of this looks at if there are any stable releases on the "supported" branches.
dww	So once the $target_major is set, the logic that tries to avoid unstable releases with extra has no where else to go and recommends the latest beta or rc or whatever.
dww	So, short term work around would be to not call "11.0.x" branch "supported" until you actually want update.module to recommend it.
dww	And long term, we'll need a bugfix to update.compare.inc to handle this (semi-rare) edge case and try to backport it as far as y'all are willing...
dww	https://www.drupal.org/project/drupal/issues/3461690
catch	https://drupal.slack.com/archives/C03L6441E1W/p1721090295905559?thread_t... seems ok as a workaround. Not sure it matters now we're in RC but for 11.1/10.4
dww	I was a bit hand-wavey with the proposed resolution in 3461690, but it's approximately correct. :sweat_smile:
catch	Thanks following that one.
Gábor Hojtsy (he/him)	I don't know why update module even suggests 11.x on 9.x? That in itself is not good, since you cannot update to 11.x from 9.x, you need 10.x inbetween.
Gábor Hojtsy (he/him)	Also relevant for this issue I think is that many sites use Upgrade Status to check for their upgrades, so additionally to the core fix, we can/should add a warning to Upgrade Status to pre-empt users from upgrading from 10.4 to 11. That would not stop them, but it may help in form them. Anyone up to open an issue?
catch	@Gábor Hojtsy (he/him) 9.5.x recommending 11.x appears to be an update.module bug that we fixed in 10.something.
dww	I don’t believe that last statement is true. From my reading of the code, once the branch you’re on is unsupported, update status will “recommend” the very latest core branch that’s marked as supported.
dww	The comments says it’s searching for the “next” supports branch, but the logic doesn’t implement that, the code never break ms out of the loop, and it only stops on the latest branch.
catch	Hmm do you know if there is an issue for that already? I think I got confused between the testing results between 10-pretending-to-be-9 and actual 9.
dww	It’s basically the same bug as the new issue I just link. Well, same line of code, maybe 2 different bugs. :joy: (edited)
dww	We could rescope the new issue to cover both.
catch	Sorry which is the new issue?
dww	https://www.drupal.org/project/drupal/issues/3461690

4️⃣ #3449815: [meta] Requirements for tagging 11.0.0-rc1 Drupal 11.0.0.-rc1 has been released, anything that needs doing?

xjm	https://www.drupal.org/project/drupal/issues/3332028 is the new issue for 11.0.0
xjm	Thread 3️⃣ is a child issue of that
Björn Brala (bbrala)	https://www.drupal.org/project/issues/search/drupal?project_issue_follow... think these need some tag cleanup with target releases. :)
xjm	And/or moving them to different metas, like 11.1 or 10.4 or etc.
xjm	Or possibly even the D12 meta in some cases
Björn Brala (bbrala)	Was triggered by a 5yr old issue for Umami :stuck_out_tongue:

5️⃣ Shall we start an issue for the Drupal 11 release landing page?

Björn Brala (bbrala)	Suggested by @hestenet (he/him)
xjm	We should!
xjm	In other-thread in a private channel I just proposed a meta -- a new meta with one child for the D11 landing page, another child for translations, other children for other pages that we might update, etc. Like the scope would be [meta] Update Drupal.org content for Drupal 11 or something.
xjm	There is already a draft for the D11 landing page/wireframe that the committers are reviewing (not sure if it is available for public feedback yet)

6️⃣ Drupal 11 documentation. Should we start separate guides for each major version or keep current ones up to date?

Kristen Pol (she/her)	Raised by @VladimirAus
xjm	@Kristen Pol (she/her) There is currently a new wireframe for D11 under development which is what hestenet's thread is related to (edited)
xjm	@Kristen Pol (she/her) Or wait, is this about the "how to ugprade to" docs? Edit: Sorry, asking the person who proposed the thread instead. :smile: (edited)
xjm	During D10 development we already tried to make a lot of the content more evergreen, but D11 will have its own new landing page.
xjm	We definitely don't want to have to create new docs for every major version for stuff that is the same or just iterated on between major versions
xjm	@VladimirAus Could you provide links to which content you mean?
Kristen Pol (she/her)	https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-8-or-...
VladimirAus	In Drupal wiki section there is Drupal 7 guide.I keep hearing from teacher and novice users that it is unclear where to find Drupal 10 documentation, they can only find Drupal 8 documentation.I found two solutions to this issues:either specify the version on the page to avoid confusion (aka Gitlab documentation)OR separate documentation guides: 10, 11, etc (e,g, Laravel or Bootstrap)
xjm	D7 needs a separate guide because D7 is different
xjm	D8+ all have roughly the same upgrade process between majors so it should be a single guide
xjm	And again I thought we had already decided on that and at least made a start last major to fix the modern upgrade docs
VladimirAus	Indeed, but people are still confused.
xjm	I don't know what this means about "only finding D8 docs"; maybe places on d.o that still say D8 when they mean "modern Drupal that is not D7"?
xjm	It will help a lot when we can archive the D7 docs
xjm	Then we don't need conditional titles
VladimirAus	Novice users think Drupal 8 and Drupal 10 are different.
VladimirAus	Most of the screenshots are of Drupal 8.
VladimirAus	Etc, etc
xjm	Ah, well that's probably true. D8 existed longer and was developed longer; Claro/Olivero have existed less time
xjm	But I think that's a separate scope of issue
xjm	Mostly we just need to update content to be evergreen rather than referencing D8 specifically which is an ongoing process
VladimirAus	I'm doing monthly sprints to replace screenshots and review all the docs, but the concerns are real.
VladimirAus	Another page I was thinking about is clear explanation of versions.
xjm	But for this specific thread, we should finish what we started with D9 to make the major upgrade docs evergreen
xjm	I am sure we already have clear explanation of version docs?
xjm	Maybe this is an SEO issue?
Kristen Pol (she/her)	Remove versions for new docs and then point to D7 on top of the guide?
Kristen Pol (she/her)	I guess that’s evergreen… yeah SEO is a problem if we remove versions
xjm	Again I thought we already did that, just some titles and URL aliases are still "8 or 9 or 10" like above
xjm	No I mean is there an SEO problem currently that people are not getting the right pages?
xjm	Re: explanation of versions etc.
xjm	We absolutely 100% have that content but maybe people are not finding it
Kristen Pol (she/her)	What about a block on right for all the doc pages that list the versions covered? Then it’s only in one place
xjm	I would personally not create massive workarounds for the existence of D7
xjm	It is EOL in 6 months
Kristen Pol (she/her)	But having the versions somewhere on the page could help with SEO
xjm	We should just treat the content as non-version-specific, leave D7 separate with D7 in its titles, and pretend as if D7 doesn't exist within modern content
xjm	Sorry I feel like I am not communicating somehow
xjm	I was talking about current SEO of people not finding things
xjm	Not SEO related to removing version info
Kristen Pol (she/her)	I understand you but I think people are googling with versions
xjm	d.o should stop caring about D7 and treat the D10+ world and release cycle as the default
xjm	Drupal is Drupal is Drupal
Kristen Pol (she/her)	We know that
xjm	Sorry I mean d.o should act that way 🙂
Kristen Pol (she/her)	But it appears to be an issue for people trying to find the content
xjm	If we mention the versions we have to update it every 2 years and we are failing at that
Kristen Pol (she/her)	So that’s the issue to solve some reasonable way that doesn’t require a bunch of updates
xjm	If we stop mentioning versions and just treat it as "this is how drupal is now" then we don't need to worry about people googling version numbers hopefully?
xjm	Because the only content available will be modern Drupal
Kristen Pol (she/her)	Perhaps… I guess we can hope that’s the case 🙂
xjm	We need to correctly archive old content though and maybe do better SEO for the upgrade guide
xjm	I don't know how 🙂
Kristen Pol (she/her)	Seems like removing the version will certainly be better than now where is says D8
xjm	Righty it should not say D8; what says D8 in the upgrade guide?
xjm	If it does that's a bug
xjm	It's a bug we started fixing in the handbook in 2019
xjm	We probably missed places because d.o has too much content
xjm	I'm just confused why this thread is a new question because we already made a decision last major to have an evergreen upgrade guide. That's what I'm trying to focus on. 🙂
xjm	So if it's a half-baked evergreen, we should finish making it all evergreen and that can be a child of the release requirements issue
VladimirAus	Removing version will make it "tomorrow's person problem". Versions should stay like in all successful projects documentations I mentioned above. And we need to review documentation every two years same way we review code. Otherwise it will be updated sporadically.
VladimirAus	Removing version won't solve confusion from non seasoned Drupalers like teachers and students.
andypost	Another question is dgo.to/user_guide and help topics in core, there's should be actual docs
quietone	@VladimirAus which documentation are you referring to? if this is about the 'Drupal User Guide', 'The Evaluator Guide', 'The Local development guide', or the Wiki guided Drupal and Develop. Or all of them?
VladimirAus	Pretty much all of them need some love, but I'm setting priority on Drupal Wiki for now
quietone	How would the contributed themes and module guides work in a versioned system? https://www.drupal.org/docs/extending-drupal/themes and https://www.drupal.org/docs/extending-drupal/contributed-modules
xjm	Updating ALL THE DOCS every two years is completely and utterly unsustainable. Even updating the upgrade guide every two years has proven unsustainable.
	We only need D7 docs to be different from D8 docs. Before D8, there was no such categorization. After D8, there need not be either.
	I think "screenshots go out of date" is a much smaller problem than "we have to create an entirely new version of the handbook every two years".
	I think we already made the decision last major that there would not be a versioned system, and I think there is significant mismatch between the topic of this thread and its content 🙂
quietone	These last comments seem to be about my questions, so I will explain. I was not sure about the topic so I asked @VladimirAus, who requested the thread. And based on that I asked another question, hoping to understand their view point. For me, that is important. And further, and again for me, working to understand the opinion of someone is separate from any opinion I have on the topic or any already made decision.
xjm	Rereading the original post, it's possible that I misunderstood and this really was a quesiton about creating an entirely new copy of the whole entire handbook every major version because screenshots are out of date. That seems like a non-starter to me. I agree that fixing the screenshots is a good idea, but I'd propose discussing alternate approaches than making copies of the handbook. (edited)
xjm	The content would be 99% the same from major to major post-D8, and the docs gate already requires updating the handbook for core changes. We just haven't applied that to changing screenshots every time we make a minor UI change or adopt a new core theme.
xjm	The whole point of the continuous upgrade path is that majors really aren't different from each other anymore.
xjm	We shouldn't imply that they are and make thousands of hours of extra work leaning into the idea that they are; we should solve the core problem. If people are finding "Drupal 8" documentation on Drupal.org, we should fix the "Drupal 8" documentation they're finding to be "Drupal core" documentation. They might also mean that they're finding "Drupal 8" documentation on the internet outside Drupal.org, which is a problem that probably exists, but I don't know that we can do anything about that. (edited)
xjm	To solve their problem, we need to know what they're doing to find docs, rather than making assumptions that they will find the Drupal.org user guide at all. (edited)
Gábor Hojtsy (he/him)	I think https://drupal.slack.com/archives/C03L6441E1W/p1721173798420199?thread_t... is the status quo, Drupal does not change that much from major version to major version because its hard to get stuff into core. Once/if more field UI redesign type or custom block AI reorg like stuff is done, this is not true anymore.This especially is getting tricky with the at least 2 year overlap of support for Drupal 10 and 11 from this month. Drupal 11 will/should hopefully change quite a bit from Drupal 10 in this same timeframe and we want to maintain docs for both.
xjm	Well feature docs are self-contained, so I think that part is okay. We made additions, we add docs for them, and the docs briefly mention that the feature was added in 10.3 or 11.1 or whichever.I think it's okay for screenshots and the like to be for the newest version possible whenever we can update them, so I would not worry about the support of multiple major versions in that case.The harder part is when to remove or move docs for deprecated functionality, I guess. But APIs that replace deprecated functionality are precisely the APIs that we would backport to maintenance minors, so we're still covered in terms of the latest docs in that regard. What we're lacking is a process for removing old docs once the last version that supports an old API reaches EOL.