Problem/Motivation
Drupal 9 will come with a new version of Stable. Initially, the plan was to replace the old Stable with a new Stable theme, which essentially would force all themes to upgrade to the next Stable theme as part of the major version upgrade. Upgrading Stable can be cumbersome. Given that upgrading to the next Stable theme comes with very little benefits, it seems unlikely that themes would be interested in upgrading unless they are forced to do so.
Proposed resolution
- Make base theme a require property in themes: #3065545: Deprecate base theme fallback to Stable
- Copy current Stable to contrib project so that it can be used with Drupal 9. There's already a namespace reserved for this.
- Create a new Stable theme with a new name for Drupal 9, following almost the same steps used to create Drupal 8 Stable in #2575737: Copy templates, CSS, and related assets to Stable and override core libraries' CSS
- Automated test for library overrides to ensure completeness
- Automated test for template overrides to ensure completeness
- Copy all the CSS, changing image paths as necessary
Copy all the images, no changesNo benefit to this step, they'll get copied when it becomes contrib, though.- Add all the libraries-override needed to stable's .info.yml
- Copy all the templates, with appropriate doc changes
- Deprecate the Drupal 8 Stable theme in Drupal 9 to be removed in Drupal 10.
Remaining tasks
- Agree on maintainers of the contrib project
- Copy code from Stable to the new project
- Decide what happens to Classy which depends on Drupal 8 Stable
- Agree on a name for the Drupal 9 Stable: #3094440: [policy, no patch] Agree on name for Drupal 9's Stable theme
- Create the Drupal 9 Stable theme and copy all the templates and assets to the new theme
- Write change record
- Remove dependency on Stable theme from core themes and tests not specifically testing Stable
- Deprecate Drupal 8 Stable (needs follow-up)
User interface changes
API changes
Data model changes
Release notes snippet
The Stable 9 theme has been added to provide backwards compatible markup and CSS in Drupal 9. More information can be found in the change record introducing Stable 9.
Comment | File | Size | Author |
---|---|---|---|
#83 | 3050374-83.patch | 125.97 KB | alexpott |
#83 | 79-83-interdiff.txt | 1006 bytes | alexpott |
#79 | interdiff_77-79.txt | 586 bytes | bnjmnm |
#79 | 3050374-79.patch | 126.71 KB | bnjmnm |
#77 | interdiff__73-77.txt | 7.19 KB | bnjmnm |
Comments
Comment #2
davidhernandezNote that if we change the name it won't be as simple as downloading the contrib theme to stay compatible. If you are doing any overrides somewhere (or who knows what) the name "stable" may be in your code somewhere. The likelyhood is low, but I think still possible. We'll need to document it.
Comment #3
larowlanIs there a link to the discussion that prompted this?
Comment #4
lauriii@larowlan The parent issue has a summary of the conclusions made in the discussion: #2659890: [Policy] [Plan] Drupal 9 and 10 markup and CSS backwards compatibility.
Comment #6
bnjmnmComment #7
lauriiiUpdated the issue summary to reflect discussions on #2659890: [Policy] [Plan] Drupal 9 and 10 markup and CSS backwards compatibility.
👏 Would you be interested in being a maintainer of the Drupal 8 core Stable subsystem as well?
After some discussions with the release and product managers, I think It would be better to keep the name of the existing theme the same to make upgrades easier.
Comment #8
xjmOne thing we discussed is that Drupal 8 stable can't be deprecated in core until we deprecate Classy. #3050378: [meta] Replace Classy with a starterkit theme is the proposed implementation for deprecating Classy and we'll want to have that work happening during the next two years in the Drupal 9 minor release cycle.
This also means we don't actually need to put code in the contrib project until later. We just need a plan for the upgrade path (for themes, for Composer, etc.).
Comment #9
bnjmnmYes, I can maintain that as well.
Comment #10
lauriiiComment #11
lauriiiReordering some steps so that they are in the order we most likely want to work on them.
Comment #12
bnjmnmComment #13
bnjmnmUpdated issue summary detailing the proposed process of creating the Stable theme for Drupal 9. This currently matches the process used for Drupal 8 Stable, which occurred in #2575737: Copy templates, CSS, and related assets to Stable and override core libraries' CSS. If there is interest in making changes to that process for Drupal 9, this is a good place to express that interest.
Comment #14
bnjmnmThis patch starts the process of creating the stable9 theme, which will replace stable. The theme is mostly unchanged at this point. It's been renamed to stable9, and other files such as tests and themes that subtheme it have been changed to reflect those changes.
The remaining test failures are all update tests to tests paths within 8.x. This appears to be due to fixtures & tests assuming the test begins and ends with a theme named "stable" being present. In general, I'm not sure of the role 8.x update tests have in 9.x and I'm working on getting that clarified. It's possible this is the first 9.x branch where 8.x update tests don't work, but it certainly won't be the last. Once I know more I'll update documentation where needed and get this patch passing all tests. Then it will be time to move templates and CSS..
Comment #15
bnjmnmComment #16
lauriiiWould we be able to remove this completely?
Classy should continue to extend
stable
because changing this tostable9
would be a BC break.We should remove everything from this file.
stable
yet. Drupal 9 will ship with both,stable
andstable9
.Comment #17
bnjmnm#14 was pretty much a misfire so an interdiff is going to be more noise than signal. The questions there can be ignored and this patch provides an attempt at the full theme.
Comment #18
lauriii@bnjmnm could you document the steps taken to generate #17 in the issue summary? 😎
Given that we are copying lots of files around, I'd recommend that we use
git diff -C -C
for generating future patches to make reviewing easier. 😇Comment #19
bnjmnmI updated steps to create Stable 9 in item #3 of "Proposed Resolution" to be easier to identify by changing them from an
<ol>
to a<ul>
, plus added some details about the process.The patch is #17 , but using
git diff -C -C
so no interdiff needed. Note that when the stable and module files are identical, the diff tends to favor saying that the file was copied from Stable.Comment #20
bnjmnmI created/populated a 9.x-1.x branch (no release yet, though) at https://www.drupal.org/project/stable, but upon re-review of the issue summary it sounds like this should be a 10.x branch as Stable(8) will be deprecated in 9 and not removed until 10 - some clarification on this would be helpful for me. Once I'm more certain of the release compatibility, I can update the README and create a release.
With this contrib Stable, I manually tested how this would work on a Drupal 9 install without stable in core/themes, particularly since Stable is hidden and can't be explicitly installed. It worked well - themes that depended on Stable or on Stable-depending themes such as Classy were able to access the contrib Stable based solely on its presence in the filesystem - no enabling required. I also manually tested the (unlikely?) scenario of contrib and core versions of Stable both present, and in this instance core opts to the contrib version.
Comment #21
lauriiiI would create 8.x-1.x to make it clear that the snapshot is coming from Drupal 8. I'm not sure how versioning contrib projects will work in the future but we would essentially create a new major version for the Drupal 9 Stable. That would probably be 9.x-2.x or just 2.x depending on how versioning is done in the future.
Comment #22
bnjmnmI've added an 8.x dev release to https://www.drupal.org/project/stable, but I'm not able to get it to install to 9.x via Composer. Tried a few combinations of
core_version_requirement:
andcore:
with no success. The resulting error is very similar to what happens with any contrib theme/module I attempt to install on 9.x, so it may be that Composer contrib requires aren't possible yet on this version? Will look into that further, but documenting here in case it's information someone has at the ready.Here's the Composer error (which admittedly I have a hard time mentally parsing even after many reads of their documentation)
Comment #23
bnjmnm@tedbow and @mixologic were able to identify why the Drupal 9 Stable could not be installed via composer. Before that is possible, it requires this issue to be completed: #3084063: Use information in info.yml files to determine project requirements, which is to integrate the
core_version_requirement
key.Comment #24
lauriiiWe only need the contrib project once we deprecate Stable. Stable can be deprecated when Classy has been deprecated. Deprecating Classy can only happen after we have a replacement for it, which means we will have to wait for some Drupal 9 minor release which will ship a replacement. It's great that we've been able to make some progress on the contrib project already, but I just wanted to call out that it shouldn't be a hard blocker for this issue. Maybe we should open a separate issue as a follow-up to discuss that?
Comment #25
lauriiiComment #26
lauriiiWe should update these because this is not the default base theme in Drupal 9 anymore. We probably should apply these updates to the Drupal 8 Stable theme too.
Comment #27
bnjmnmAddresses both items from #26
Comment #28
lauriiiShould we document why we're skipping these?
Nit: I guess it isn't opting out anymore since Stable isn't the default anymore. Maybe
Themes that decide not to use Stable 9...
would work?🗑️🎉
Comment #29
bnjmnmI've been on the fence about this as well, although for slightly different reasons. I revisited #2575737: Copy templates, CSS, and related assets to Stable and override core libraries' CSS hoping to be reminded of what the justification was for copying the images but I didn't see anything there. Now I'm unsure where/if I saw such a thing.
My main "against" regarding the copying of image assets to Stable9 is that it's considerable overhead for files that are unlikely to have their contents changed. Based on Git history of images in core/modules and misc/icons there is no history of this. If an image needs to be changed, it's probably better if a new image with a different name is added anyway. The one exception that comes to mind is if a security issue is discovered in an SVG, in which case it would be changed in Stable anyways.
My main "for" for copying image assets is for when it becomes a contrib module, to avoid issues like the one in #3045216: Asset paths pointing to core/misc folder assume Claro is installed in core/themes . The location of a contrib theme in the filesystem can't be certain, so the only relative paths guaranteed to work are ones within the theme.
Based on my for/against assessment, my preference would be not copying image assets to the core Stable9 as there's little evidence it is necessary. Once moved to a contrib theme, the image assets should be copied so there aren't issues regarding the location of the theme in the filesystem. Perhaps that could be accompanied by a followup to look into other ways of addressing the issue of relative paths and uncertain locations of contrib themes.
Comment #30
bnjmnmThis item addresses the points in #28 including not copying image assets. It sounds like @lauriii and I don't yet entirely line up regarding what do to when the theme is moved to contrib, but we're in agreement that it's best to not have these assets copied into Stable 9. That's nicely in scope here.
Comment #31
lauriiiGood points @bnjmnm! I totally forgot that contrib was unable to use those images even though I worked on some related issues in Claro. 🤦Moving images to the theme would make sense from the perspective of making it easier to move the theme to contrib, but besides that, it seems to have no value. Maybe we should keep the icons in core for now, and copy them to Stable when it gets moved to contrib?
Comment #32
bnjmnm#31
Yep, that's exactly what I was hoping for too. Updating the issue summary to reflect that.
Comment #33
lauriiiLet's reroll this now that #3101787: Follow-up to #2849628: Copy change to Views UI module has been committed.
Comment #34
bnjmnmRerolled to reflect the changes in #3101787: Follow-up to #2849628: Copy change to Views UI module
Comment #35
xjmTagging for a followup to discuss the policy of copying assets to Stable themes.
Comment #36
bnjmnmCreated #3105209: [policy, no patch] as of Stable 9, do not copy image assets unless they have changed. to officially discuss the approach of not copying all images to Stable 9.
Comment #37
lauriiiLet's update #34 to copy the assets to the Stable 9 theme until we have decision on #3105209: [policy, no patch] as of Stable 9, do not copy image assets unless they have changed.. Copying assets to the Stable theme shouldn't affect module or theme developers at all meaning that this change can be reverted later.
Comment #38
bnjmnmGood point on #37, the image assets change would not be disruptive so it doesn't need to postpone this issue. This has all the changes up to #34 but with the images brought back + the paths to them in CSS.
An additional change was I remove stable9.theme as there's no need for it at the moment.
Comment #39
lauriiiI guess a follow-up question related to the icons is whether we should copy all icons to Stable regardless of if they are being used? I tried to scan through the icons and it seems like we are potentially missing some icons if the scope is to copy all the icons, and we also have icons in the folder that are not being used anywhere.
Comment #40
bnjmnmIf images need to be copied I'd say yes to copying all icons largely because there's built-in uncertainty to copying only those in use and no easy way (that I'm aware of) to check with automated tests. Bringing them all over seems to be the most review-friendly and unwanted-surprise-preventing way to go about it. I think partial copying of icons may lead to the need for increased review time that could be better spent creating a test that would address the only concern preventing agreement on not copying images at all #3105209: [policy, no patch] as of Stable 9, do not copy image assets unless they have changed.
The intent was to copy all the icons, and
diff -rq core/misc/icons/ core/themes/stable9/images/core/icons/
reports no differences - perhaps there's an additional location I missed?Comment #41
lauriiiAdded change record as a step in the remaining task. Once #3105209: [policy, no patch] as of Stable 9, do not copy image assets unless they have changed. is done, we might have to make some additions to the CR based on the result.
We should also open a follow-up for deprecating Drupal 8 Stable since we can't do that until we've removed dependency to Stable from code depending on that (Classy and all the themes extending Classy).
Comment #42
DamienMcKennaTagging as a requirement for Drupal 9.0-beta1.
Comment #43
DamienMcKennaComment #44
bnjmnmNow that #3105209: [policy, no patch] as of Stable 9, do not copy image assets unless they have changed. is complete, this brings back #34, which does not copy image assets, but also adds an images directory with a README explaining what it's there for and the circumstances that would lead to it being populated. The interdiff comes from #34 for that reason.
Comment #45
bnjmnm#44 didn't apply due to needing a reroll.
Also created an alpha release at drupal.org/project/stable/ to verify it was possible to install on D9 via composer. This is possible, but requires the command
composer require 'drupal/stable-stable:^1.0'
vs the expectedcomposer require 'drupal/stable:^1.0'
. @traviscarden is familiar with what causes this hyphenizing and will do a better job explaining it than me, so he'll be commenting with some details on why that is happening.Comment #46
TravisCarden CreditAttribution: TravisCarden at Acquia commentedThe hyphenation is a feature of the Drupal.org Composer Facade for handling namespace conflicts caused by making submodules and subthemes available directly via Composer (e.g.,
composer required coder_sniffer
, a submodule of Coder). I would expect there to already be something available asdrupal/stable
. Having tested that hypothesis, I see thatcomposer require drupal/stable
seems to know about it, but I can't get find a version that's installable or find any reference to it in the endpoint responses, so I can't determine where this conflict came from. But it seems to me a safe assumption that some kind of namespace conflict is at the root of this.Of course, since @bnjmnm got the
composer require
string from the drupal.org UI, and it does seem to work, this detail is probably not important to explain decisively.Comment #47
xjmThe followup for deprecating Stable 8 will need to be postponed on the work to deprecate Classy with the starterkit initiative.
There's a bullet I think is missing from the remaining tasks. Should we work to make core's themes extend Stable 9 instead of Stable 8? It could be a lot of ugly, tricky work, but OTOH it also might not be because:
Furthermore, if we don't make them depend on Stable 9 instead (or on nothing, is the other option, but I've strong concerns about that), then they would also have to be deprecated before Stable 8 is removed, and we don't want that because at least two of them are modern themes under active development.
So, we need a plan for how Bartik, Seven, Umami, and Claro will relate to Stable 8 or Stable 9. (The answer might be different for Bartik and Seven since they are are on a path to be replaced with Claro and Olivero sometime in the future.)
This plan doesn't have to block commit for this issue, but it does need to have an issue filed.
Comment #48
lauriiiBased on previous discussions, the plan is to make core themes extend Stark to ensure that core themes are kept up-to-date in future. This is also documented in #2659890-35: [Policy] [Plan] Drupal 9 and 10 markup and CSS backwards compatibility. Yesterday, @bnjmnm opened an issue for this. We also just added it to the roadmap: #2659890: [Policy] [Plan] Drupal 9 and 10 markup and CSS backwards compatibility.
Comment #49
catchBumping to critical since this is blocking the beta.
Comment #50
bnjmnmThis is a reroll plus:
- simplifies some url() paths to images
- corrects template comments that shouldn't state "default theme implementation"
- removes libraries-override that replace files that no longer exist in core
- added some missing assets from misc/
The new patch is smaller than #45 as some of these changes resulted in less overall changes to report when using
git diff -C -C
as there were more 100% matches with existing files.For manual testing, some things to note
- Stable 9 must be enabled before changing an enabled theme's base theme to stable9. The easiest way to do this is set a base theme to stable9 on a disabled theme, then enable it. This enabling will enable stable9 as well, and then it is possible to change any base theme to stable9 without error.
- It shouldn't actually effect testing, but could be confusing if this issue lands while that happens: Core themes are very close to having base theme set to false. This will happen once this issue is complete #3115223: Remove Stable as a base theme of core themes
Comment #52
bnjmnmThe test failure that kicked this back to "Needs work" was an unrelated intermittent failure of QuickEditIntegrationTest. Ran the test again to be certain and it's fine.
Comment #53
lauriiiShould we use the shorter path here too?
Let's update these files with the theme override documentation.
layout_discover
module since we have overridden the templates from there too?./core/misc/normalize-fixes.css
been excluded on purpose?./core/misc/print.css
been excluded on purpose?Any thoughts on expanding the test coverage to include tests that ensure that referenced files are pointing to existing files and that we are not overriding non-existing assets?
Comment #54
bnjmnm#53.1-2 addressed those neglected files
#53.3
It looks like this is an issue with both layout_builder and layout_discovery. I reviewed the make-stable issues for both and neither suggest that the omission of CSS was intentional.
Layout discovery stable #2834025: Mark Layout Discovery as a stable module
Layout builder stable #3041053: Mark Layout Builder as a stable module
I suspect this was overlooked because the CSS is not in the /css directory. I added libraries for both module's layouts.
#4
Yes, as extends the normalize.css library, which isn't currently included in Stable. My thought was to match the approach from #2821525: Update normalize.css to the most recent version and only copy normalize.css (and normalize-fixes.css) to stable if the library is updated.
#5
Has ./core/misc/print.css been excluded on purpose?
It was, but this made me reconsider. The file is not included in any library, but it is added directly in book-export-html.html.twigStable's version of that template just links to
misc/print.css
, which I initially thought was intentional but now I'm thinking it was overlooked. I updated Stable 9's template to link to the Stable 9 CSS.#6
Great idea and easy to implement! Had to update the test anyway to include the new layout library overrides. This will prevent the stale overrides we ran into as part of decoupling!
Comment #55
lauriii#54.4 Since this issue is still open #2642122: Overriding already overridden libraries-override requires knowledge of previous libraries-overrides, I'm wondering if we should ship normalize.css as well in Stable, at least for the Drupal 9 version. This way if we want to update normalize.css in a minor release of Drupal 9, we don't have worry about any potential disruption.
Comment #56
xjm@lauriii is going to work on the change record for this issue.
Comment #57
bnjmnm#55 is a good idea. I implemented that here. That the version specified in stable/normalize is intentionally set to "8.0.1" since that will be the version in Drupal 9. The patch will work with either version of normalize since it uses git diff -C -C, but it's probably important to state. This should not get committed until #2821525: Update normalize.css to the most recent version is committed. That issue does not prevent work from happening here, however, so I'm not changing the status to postponed.
Comment #58
lauriiiI'm finished editing the change record.
Comment #59
lauriiiIf it seems like it will take long for us to land #2821525: Update normalize.css to the most recent version, we could consider adding normalize.css 3.0.3 to Stable 9 and update it to 8.0.1 as part of #2821525: Update normalize.css to the most recent version.
Comment #60
xjmAssinginf to @lauriii for review.
Comment #61
bnjmnmAs a precaution in case #2821525: Update normalize.css to the most recent version does not land, I was asked to provide a version of the patch that provides normalize.css 3.0.3. This approach results in a larger patch, because it's not possible to use
git diff -C -C
as the diff needs to explicitly provide normalize.css 3.0.3, as opposed to copying whatever file is in that path. The patch that does this is named 3050374-61_explicity_uses_normalize_303.patch.If #2821525: Update normalize.css to the most recent version lands, use the 3050374-61_assumes_normalize_801_landed.patch instead. This is just the patch from #57 but named in a way to make it evident how it differs from the other patch. Even if it's necessary to go with the normalize 3.0.3 patch, reviewers should do their reviewing on this patch as it's much easier to navigate, and the only difference between the two is the normalize.css version being loaded.
Comment #62
xjmIt's not as a precaution against the issue not landing; it's a combined patch so we can test both together while working on this issue and until such time as it does land. :)
Comment #63
bnjmnmAh, #62 makes sense. This patch combines the changes for this issue with the ones in #2821525: Update normalize.css to the most recent version
Comment #64
DyanneNovaI've tested the patch in #63 using Bartik and Seven. I was able to enable Stable 9 as the base theme for both successfully. I found a few bugs on the Status Report page when Stable 9 is enabled as the base theme for Seven, and have attached screenshots.
I'm going to set up a Wraith test to run overnight to see if anything else pops up.
Status Report using Stable
Status Report using Stable 9
It looks like the counter issues are coming in here:
.system-status-report-counters__item {
width: 100%;
margin-bottom: 0.5em;
padding: 0.5em 0;
text-align: center;
white-space: nowrap;
background-color: rgba(0, 0, 0, 0.063);
}
The h3 borders are coming in here:
.system-status-general-info__item-title {
border-bottom: 1px solid #ccc;
}
And the extra box border and margins are coming in here:
.system-status-general-info__item {
margin-top: 1em;
padding: 0 1em 1em;
border: 1px solid #ccc;
}
Comment #65
catchOn #64 it's my understanding that the current patch doesn't make Seven depend on Stable 9, and rather than update it to be based on Stable 9, the direction is to remove the dependency on Stable altogether in issues like #3117217: Decouple core theme dependency on functions in stable.theme. Either way that seems like good information to know for a possible future patch, but not blocking here.
Comment #66
catchDouble checked with @lauriii and this testing is indeed out of scope for this issue. We should make sure there are follow-ups to update the various core themes and it is useful advance warning for those.
Comment #67
lauriiiIt seems like there are some changes to Umami, Bartik, Seven and Claro that seem out of scope.
Comment #68
catchThe most recent patch here is the combined patch with normalize.css. Re-uploading the second patch from #61 which is the one that actually needs review. (no credit please)
Comment #69
bnjmnmNo longer postponed: #2821525: Update normalize.css to the most recent version landed. The patch in #68 is the current patch for review.
Comment #71
bnjmnmReroll
Comment #72
alexpottAs far as I can see this is not necessary. Can be an empty array.
This does not appear to be necessary either.
Comment #73
lauriiiGood catch @alexpott! These are indeed not needed since #3110862: Remove simpletest module from core has been committed. I fixed these and one indentation mistake I noticed in the patch.
I reviewed patch with following steps:
git diff -C -C
which will create comparison to core module files.gfind ./core/modules -name *.html.twig ! -path "*/tests/*" ! -path "./core/modules/help_topics/*" ! -path "./core/modules/migrate_drupal_multilingual/*" ! -path "./core/modules/workspaces/*" ! -path "./core/modules/config_environment/*" -printf "%f\n" | sort > module-templates.txt
gfind ./core/themes/stable9 -name *.html.twig -printf "%f\n" | sort > stable-templates.txt
diff module-templates.txt stable-templates.txt -y | less
gfind ./core/modules ./core/misc ./core/assets/vendor/normalize-css -name *.css ! -path "*/tests/*" ! -path "./core/modules/help_topics/*" ! -path "./core/modules/migrate_drupal_multilingual/*" ! -path "./core/modules/workspaces/*" ! -path "./core/modules/config_environment/*" -printf "%f\n" | sort > module-css.txt
gfind ./core/themes/stable9 -name *.css -printf "%f\n" | sort > stable-css.txt
diff module-css.txt stable-css.txt -y | less
Drupal\KernelTests\Core\Theme\Stable9TemplateOverrideTest
failsDrupal\KernelTests\Core\Theme\Stable9LibraryOverrideTest
failsDrupal\KernelTests\Core\Theme\Stable9LibraryOverrideTest
failsComment #74
lauriiiHere's #73 but generated with
git diff -C -C
./Comment #77
bnjmnmThis removes the files that snuck into #73 while keeping the intended changes
Comment #78
lauriiiIt seems like we should add these files to the
.stylelintrc.json
as ignored files. 😇Comment #79
bnjmnmLINT!
Comment #80
lauriii#77 and #79 addresses the test failures and linting errors. I think this is ready to go back to RTBC 🚣♀️
Comment #81
lauriii@alexpott mentioned on Slack that it would be a good idea to have release notes on this so I went ahead and added that.
Comment #82
bnjmnmComment #83
alexpottThis is all looking good. I've got some very minor nits that the patch attached fixes.
I've checked all the urls are pointing to real files and the correct ones. And read through the entire patch :)
Let's add
/* stylelint-disable selector-type-no-unknown */
to the file instead of excluding it. More future proof. Or in fact let's do that in a follow-up because then we can do the core file too.The extra line added here feels unnecessary. There are plenty of files that don't have this space. Even some added here.
In Stable the first line of this theme has been changed to
Theme override to display all the fields in a row.
Comment #84
lauriiiThe interdiff in #83 looks good so +1 for keeping this as RTBC.
Comment #85
alexpottCommitted 2505346 and pushed to 9.0.x. Thanks!
Comment #88
quietone CreditAttribution: quietone commentedA follow up was asked for in #41, for deprecating Drupal 8 Stable. That work has since happened, in #3308985: [Meta] Tasks to deprecate Stable. Therefore, I am removing the tag.