[META] Add classy_dev and minor-branch theme snapshots to allow fixing markup bugs within minor releases without front-end disruption

Tagging for review. ;)
Also, I set those 4 issues as children where possible, related if they already had legit parent issues.
Summary update to refresh the status of everything (namely, lots of blocked issues).

Thanks for the pointer, @gapple.
Adding these to the list of bug fix issues that have ground to a halt as a result of our policy:
#2945727: Form radios/checkboxes elements should have js-form-wrapper class
#2988461: Radios template does not apply form-radios class

#2988461: Radios template does not apply form-radios class is now a child, so it doesn't need to be related.
Adding the 'blocker' tag.

Elevating to major since this is blocking a large (and growing) number of bug fix issues.

Moved the current list of bugs up in the summary and simplified the proposed resolution section.

Also, it's a "plan" that needs a review at this point, so NR seems a more appropriate status.

Personally, my draft policy would look something:

• If it's a bug fix, fix it in stable and classy, update the tests to ensure it's fixed, and generate a CR about it.
• Update the "BC" policy handbook page to say "we try not to change things, but will fix bugs. Here's a list of CRs that you can follow if you're interested in changes to these templates (where that link should go is @todo).
• We attempt to only do these "BC"-breaking markup changes in minor releases. E.g. it's cool to fix any bugs in 8.7.x now (prior to 8.7.0 official), but we only change classy and stable templates for 8.6.x if it's at least "major" (given our existing standards for what's major/critical). Critical and major are eligible for patch-release fixes + CR, everything is can be fixed in a new minor release.

More or less. Edit: Retracted. #7 is a much better solution.

I'm strongly -1 to "don't fix anything until 9.0.0", which seems to be the net effect of our current practices / policy.

Totally open to counter proposals and other approaches. I am not much of a front end developer, and I don't regularly feel the pain that must have led to this BC policy in the first place. But I find our current situation untenable.

Thanks,
-Derek

Re: #7: Seems great to me!

If we change the testing* profiles to use classy-8-X as their theme, we can fix our test coverage as we fix bugs.

Theme builders can choose what to use as their base according to their needs/desires.

Everyone can always get a diff of the "stable" vs. "current" versions so they can see / adopt changes and fixes, regardless of their base theme.

We can still have CRs for everything that modifies (classy|stable)-*-*.

Major downside seems to be slightly more work to open up each new branch, but I'm sure we'd work out easy ways to do it.

Adding #7 as a proposed solution in the summary.

Hopefully better title.

Moved this line near the top of the summary and put it in bold:

How are we actually supposed to fix the bugs in core? The 'testing' profile uses the classy theme. So if we try to fix a bug, we're supposed to update the tests, but if we can't fix the classy templates, the tests will never pass. Deadlock ensues.

That's the heart of the matter for me.

Re: @xjm in #14:

I don't think we'll be changing the BC policy (and we definitely won't be adding tests to HEAD that fail).

So how do we ever fix bugs unless they're major or critical? We can't change classy (due to this policy). We have to fix the tests (due to other policy and good sense). Tests run against classy (due to policy? or at least practical reality). Deadlock. :/

The problem with changing Stable and Classy is that sites with existing themes may already have worked around these bugs, and fixing them in HEAD can break and conflict with however existing sites have worked around them.

I get that, and am totally sympathetic. I'm retracting my proposal from #6, and I never put it in the summary. That's why I love a "classy that never changes but tests don't care" vs. "classy-X-Y that changes and tests can use" solution from @shaal in #7.

we can file issues against Drupal 9 rather than adding failing tests

But that means we don't fix normal and minor bugs for another 2-4 years, right? Ugh.

Here's the detailed wording of the actual policy

Thanks! Not sure where that came from vs. the handbook page, but yes please, let's update the handbook to at least match that.

So it's not "no changes, ever"; it's "only certain kinds of changes based on impact vs. disruption at committer discretion".

But in practice it means "all bugs that touch markup are blocked on @lauriii". And it sets us up for a conflict every time, since us bug fixers want to fix bugs, and the front end managers want to minimize disruption (both parties for all the right reasons). The combo of both being a bottleneck to progress and being regularly torn between "let's fix" vs. "let's not disrupt" has got to be a recipe for burnout (on all sides).

I just know I'm tired of trying to fix core, running into this deadlock, having to post/maintain un-committable patches that I have to tell composer to apply to my sites, and watch countless hours of contributor time go down the drain because we haven't come up with a viable and sustainable solution to this thorny issue.

That's why I love #7! I think it would totally solve this problem for everyone, at the small cost of a bit more work to open a new minor branch of core (fork the current classy/stable themes, update all the testing profiles to use the new name, maybe a few other things TBD).

New thought, haven't really processed it, but sharing for consideration: do we need separate versions of classy for every minor branch? What if we just had "classy" (maybe "classy-stable" in D9) vs. "classy-dev" or "classy-current" or whatever. So, we have a version that we can change to fix (all) bugs, which is what tests run against, vs. the "original" version at the start of that major release. Does anyone actually care / need to have classy-8-6 vs. classy-8-7? I can see some benefits to keeping them branch specific (e.g. smaller incremental changes per @seanB in #11), but it does mean we'll accumulate more themes + templates over time. Added that as option B to the summary for now. I still think A might be better, but let's discuss. Another reason to pick solution A: once 8.7.0 is out, the classy-8-6 theme becomes "stable" so folks could do a 1-time reconciliation to "catch up" if/when desired. So yeah, even though it slightly bloats core to keep forking these themes, A is probably the most flexible solution all around, and gives theme builders the most options.

Note: I'm totally option to other solutions. Please keep the alternate proposals coming if folks have other ideas! I'm not attached to any particular solution (yet), but I'm sure this is a major problem we have to solve to keep Drupal moving forward in a healthy way.

Thanks!
-Derek

p.s. Also tagging for 'release manager review' since I believe this has implications for them, not just the frontend framework manager(s).

Proof-of-concept patch to add a classy_8_7 theme to core. Changes the relevant testing profiles to use classy_8_7 not classy itself. One test case passes locally. ;) Let's see what the bot says. I'd be shocked if this works, but who knows? ;)

p.s.: this patch was basically generated via:

# git pull to latest 8.7.x
cd core/themes
cp -rf classy classy_8_7
cd classy_8_7
perl -pi.bak -e 's/classy/classy_8_7/g;' *.yml templates/*/*.twig
# edit README manually
cd ../../profiles
perl -pi.bak -e 's/classy/classy_8_7/g;' test*/*info.yml testing/config/install/system.theme.yml
cd ../../..
find -name '*.bak' | xargs rm
git add core
git diff --cached > 3031198-16.classy_8_7_poc.patch

More or less... ;)

p.p.s.

1. I did *not* change bartik or seven to extend classy_8_7 instead of classy, although we probably want that. TBD.
2. Nor did I carefully review stuff in classy_8_7 that could properly be cleaned up or fixed now that it's not the "stable" classy. That should all happen in follow-ups to keep this as straight-forward a clone of classy as possible as the initial commit.
3. Nor did I touch / address a "stable-dev" option. Maybe that doesn't need to happen at all, "stable" can be totally stable and mothballed forever. AFAICT, all our tests use classy (or their own custom test themes), so maybe we don't care about "stable" at all, and can simply ignore it until D9. TBD.
4. A totally different approach would be for classy_8_7 to use classy as a base theme, and then only add templates or CSS files that change. That might be better. Maybe more confusing and weird. TBD.

Discuss! ;)

Thanks,
-Derek

Here's #18.4 in patch form. Obviously *way* smaller and probably better. The idea would be to simply add templates to this as needed whenever they need to diverge from classy itself.

Interdiff is pointless in this case.

I could post a patch here that fixes #2419131: [PP-1] #states attribute does not work on #type datetime using this approach if that would be useful for comparison.

Thoughts?
-Derek

For comparison / review / clarity (?), here's #19 + #2419131-111: [PP-1] #states attribute does not work on #type datetime, modified to add the fixed datetime-wrapper.html.twig to classy_8_7, not touch classy or stable at all, and still have a working test. At least the test passes locally. ;) What say ye, bot?

Re: #16: Wow, only 50 fails! That's amazing. ;) Way better than I thought. Most are of the form:

Drupal\Core\Config\UnmetDependenciesException: Configuration objects provided by block_test have unmet dependencies: block.block.test_block (classy)

which makes perfect sense, since I didn't update anything to account for this. A few others are related, but not identical failures.

The one set of failures that give me more concern look like this:

Rest.Drupal\Tests\block\Functional\Rest\BlockJsonAnonTest
1) Drupal\Tests\block\Functional\Rest\BlockJsonAnonTest::testGet
Failed asserting that Array &0 (
    0 => '4xx-response'
    1 => 'config:block.block.llama'
    2 => 'http_response'
) is identical to Array &0 (
    0 => '4xx-response'
    1 => 'config:block.block.llama'
    2 => 'http_response'
    3 => 'user:0'
).

Not sure why the user:0 is getting inserted there or what that has to do with the theme. ;) But maybe it's a slightly confused assertion that's happening because the block itself is fubar without the right config? Or something? ;)

I *think* #19 and #21 will work way better, since classy will still be enabled, all the config will be there, etc. I'll await full bot results to confirm, but I'm cautiously optimistic that the subtheme-of-classy approach will make this all go pretty smoothly. There might only be a few legit test failures that need investigation and update for #19.

#21 is only to show how adopting this approach would let us fix bugs. That's not intended to be committed.

@shaal and I discussed #24 in Slack. He had missed comment #19 and subsequent comments. Oh well. ;) There are various problems with #24, not worth going into here.

#19 only has 10 fails. Getting closer. ;) Way better than 50...

Some require more investigation. I think many are because #19 fails to copy over the classy theme regions, which we need to do here. whoops, I guess not -- classy doesn't define regions of its own. ;)

However, this one is pretty obvious:

1) Drupal\Tests\system\Functional\System\ThemeTest::testThemeSettings

Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'core/themes/classy/logo.svg'
+'core/themes/classy_8_7/logo.svg'

Before I spend any time to fix this test, it raises the point of how we really want to name these sub-themes. To prevent having to remember to fix this same test for each new minor branch, perhaps we should have:

• classy - the stable version of classy, basically unchanged since 8.0.0. In 9.0.0 we could call it "classy_stable", "classy_base", or even "classy_9_0"
• classy_MAJ_MIN, e.g. classy_8_7 - the stable version of classy at the time 8.7.0 is released. Once it's out, it's also stable.
• classy_dev - the current dev version of classy. During the life of 8.7.x branch, we can change this as needed. When 8.8.0 is close, we clone this into classy_8_8 and leave that stable from then on.
• When 9.0.0 is getting close, we move the overridden templates from classy_8_LAST into classy_base (or whatever we call it), remove all the classy_8_* directories, and reset classy_dev to an "empty" subtheme again.

Testing profiles always use "classy_dev".
Tests can be written to always target "classy_dev" (e.g. for the test fail listed above).
Theme builders can choose whether to extend classy itself, classy_MAJ_MIN, or even classy_dev depending on their needs.

Open questions:

1. Are we cool with "classy_dev"?
2. Do we care about "stable" for this? I mostly care about this from the perspective of tests, and therefore classy*. But maybe to help people who extend stable to have a chance at incremental bug fixes and improvements, we can do the same thing. We'd have stable_8_7 (everything as-is at the time of 8.7.0 release) and stable_dev for any bug fixes to stable over the life of the 8.7.x branch, to be cloned and released as stable_8_8 when 8.8.0 comes out.

I'd love to answer those before I roll a new patch to fix the remaining test failures.

I'd also love more feedback from the release/frontend managers on if this is going in the right direction.

Thanks!
-Derek

Okay, I think this fixes all the tests via embracing "classy_dev" as the way forward. Seems to work locally. Let's see if the bot agrees.

Interdiff relative to previous patches is basically pointless. The patch is the interdiff. ;)

Added the current approach as option C to the summary.

Note: I added classy_8_7 in patch #27, but that's premature. We should only do that on the eve of the 8.7.0 release. It's basically here as more proof-of-concept. I can easily strip that out in a subsequent patch if all the core committers are on board with this general approach.

Minor fixes and updates to option C in the summary.

Bah, making bartik and seven use classy_dev as their base theme totally confuses all the update tests. :( That's probably way too disruptive a change at this point, anyway. Reverting those little bits seems to make update tests start passing again locally. I didn't run the full suite, but the first few pass so I'm optimistic this fixes everything.

Also, since classy_dev doesn't yet define any CSS of its own, the tests (like core/modules/system/tests/src/Functional/System/ThemeTest.php) that are assertRaw()'ing to find their base theme need to search for "classy" not "classy_dev" after all. My bad.

This patch also removes the (premature) classy_8_7 from the patch (per #28).

So, I think this might actually be all green and a potentially viable candidate to commit. ;)

Of course, I'd still love feedback from all the core committers and other stake holders about this.

In the absence of a better solution, I'm all in for option C at this point. I want this to land before 8.7.0 so we can unblock all this stuff in the 8.7.x series.

Onward! :)

Cheers,
-Derek

whoops.

Drat, I missed two. ;) These both pass locally now. Fingers crossed for a happy green bot result this time...

Weird. That fail doesn't make sense. It's barfing in the 'stark' case, which is untouched by my patch. Trying to run this case locally passes just fine. I re-queued #34 for testing. I suspect that was a random fail.

Meanwhile, here's a version that tells this test (all the OffCanvass tests, for that matter) to test against both classy and classy_dev (along with all the other core themes). This, too, passes locally.

Great! Bot is happy with both #34 and #36 as expected. Phew. ;) On second thought, it seems better/more consistent to only test classy_dev in this test, not both classy + classy_dev (like #36), basically to train core devs to use classy_dev in all tests from now on.

Updated summary to enumerate pros/cons for option C. Lots more pro than con! ;)

Updating title, and moving this from a plan to a task. Obviously we can change it again if another approach develops, but for now, I think this is the way to go.

Tagging for 'needs documentation updates' at the very least for the Frontend BC policy handbook page, perhaps some test-related documentation that explains how/why all core tests use the classy_dev theme by default. Not entirely sure where those docs (should) live, yet. TBD.

Trivially adding stable_dev while we're at it, so we can use the same policy/solution for both classy and stable. Minor updates to the new classy_dev/README.txt, too.

We probably could do a more thorough audit of our tests to move more references to stable and classy to their _dev cousins. TBD if the core maintainers want that. What's in the patch now is basically the minimum change to get everything passing again and unblock all the other issues. If we want a follow-up to do the more thorough "Port core's tests to use classy_dev and stable_dev", I'm down to help with that.

And now, to prove in code / testbot results exactly why/how we need this. Pair of patches and a set of interdiffs:

3031198-38.classy_dev_plus_2419131_fix_and_test_will_fail.patch is patch #37 from above, plus both the bug fix and the new tests for #2419131: [PP-1] #states attribute does not work on #type datetime, but with the "classy should remain intact" approach that our existing policy mandates (except for exceptions, ugh!). The new test fails because the classy templates are still broken, so even though we fix core/modules/system/templates/datetime-wrapper.html.twig, the templates the test actually uses are wrong.

3031198-38.classy_dev_plus_2419131_fix_and_test_and_dev_templates_should_pass.patch is the ...will_fail patch plus the new templates in classy_dev (and stable_dev for completeness, not really necessary). This should be green.

Posting interdiffs of both relative to #37, plus an interdiff between these two (so you see only the 2 new templates added to (classy|stable)_dev.

This is why we need this policy change, and why option C is so elegant and happy. Can I get a witness!?! ;)

What else can I do to make this a reality? Tagging for 'Needs change record', but I don't want to write that until there's more indication from the core maintainers that they like the approach.

Thanks,
-Derek

p.s. I'm hiding all these files from the summary, since they're not really for consideration to commit, they're only here to demonstrate how option C works in practice.

Minor summary updates, fixing links, etc.

Even though I desperately want this in before 8.7.0, adding it to the d9readiness issue tree based on Slack convo w/ xjm and Gabor.

Yay, the bot agrees with me in #38. ;) I hope that clarifies beyond all doubt how/why we need this.

Behat\Mink\Exception\ElementNotFoundException: Element matching css "label[for="edit-datetime"]" not found.

That's because the "intact" classy templates don't have a label for datetime elements at all.

Meanwhile #38.should_pass is happy and green, since that adds the modified template to classy_dev and now all is happy.

Huzzah!
-Derek

p.s. The random fail from the first test of #34 should be resolved at #2946294: Fix race conditions in OffCanvasTestBase - no new follow-up needed.

Hah, amazing: #37 applies cleanly to 8.6.x, too. ;) Queued that for testing, in case the core maintainers want this in 8.6.x so we can backport markup bug fixes there, too. There would never be a classy_8_6, and anything that touches 8.6.x branch classy_dev will have been cherry-picked from the 8.7.x branch. It would let us fix bugs and still have working tests. Themes that extend classy in 8.6.x would have to merge the classy_dev templates + fixes into themselves, or switch to using classy_dev as their base theme if they want to live dangerously. ;) I'm down, if the core committers are up for it. All the README.txt text is still valid, even for the 8.6.x branch. There won't ever be a classy_8_6, but there will start being one for classy_8_7 if all goes well.

Trimming down option A in the summary (removing my commentary from #8), since C is better. Other minor edits to keep the summary updated.

Re: #45:

The new test in the patch is DatetimeStatesTest, which covers the changes in datetime-wrapper.html.twig?

Basically, yes. I don't want to get distracted on those details, we should discuss at #2419131: [PP-1] #states attribute does not work on #type datetime if you want. #37 is only here as an example of how this policy would let us safely fix bugs and move forward.

If we go this route, should we have a an equivalent test that we aren't changing classy for each classy-dev change, even if we just do a hash of the file contents?

I don't think so. That seems like even more friction for fixing bugs (which this proposal is trying to eliminate or at least reduce). We're not going to be consistent about it, and it's a pain to have to remember. Seems like an undue burden on people trying to fix markup bugs. I think we're very good about having "gates", reviewing such things by eye, having the committers enforcing our policies, etc.

If anything, once we adopt this new policy, I'd be open (in a follow-up issue) to have a single test that checks the file hashes of all templates in (classy|stable) where any failed assertion prints out "You should never change templates in $theme, touch {$theme}_dev instead, see @handbook_link for details" (more or less). We could get this test working properly once, and then never have to think about it again for the rest of that major release series. When we refresh the templates during the 9.0.0-beta* phase (?), we can fix the data source for this test (probably a huge array of file paths/names and hash values) once, and leave the test (and templates) alone for the entire lifespan of D9. That would fail on any proposed patch that does it wrong, help the devs understand they're violating policy, and point them in the right direction.

But relying on incrementally adding such tests as we change the _dev themes seems brittle and yet-more-PITA-for-people-trying-to-improve-core.

All that said, thanks for your input and feedback!

Cheers,
-Derek

@andrewmacpherson re: #47:

First, thanks for your thoughts and feedback!

A) I'm totally not attached to stable_* here at all. I only really care about classy, since that's what the entire test suite uses, which is why we basically can't fix bugs that involve markup. I added stable_dev to the proposal since @shaal thought it would be a good idea, but I'd be happy to remove it again.

B)

Likewise later numbered versions like stable_8_7 would be snapshots of modules at that release milestone.

Right, but we can't see what the incremental changes are unless we have somewhere to do the incremental changes. ;) The point of stable_dev is that if/when we need to change a template, we add the updated template to stable_dev. So everyone knows that the only templates that have had to change since stable are the ones in stable_dev.

C)

If we have to maintain updates to stable_8_7 during the whole development period between 8.6.0 and 8.7.0, that means every change in module templates/CSS during that time has to be duplicated correctly, which sounds error-prone to me.

That's not the proposal. See option C. We only ever change templates in (classy|stable)_dev. Between 8.7.0-betaLAST and 8.7.0-rc1, we do a 1-time clone of classy_dev into classy_8_7, then never touch classy_8_7 again. classy_8_7, like its parent classy, would never be modified, and is provided as a stable thing to extend in a theme if you want to catch up to the bug fixes and improvements that happened in classy_dev until 8.7.0-rc1 is out. At that point, you're "stuck" with the state of classy_8_7 until you decide if/when you're ready to jump to classy_8_N, or work-around the bugs yourself (like now).

D)

Wouldn't be simpler to delay creating the stable_8_7 until 8,7.0 is tagged?

Yes, that's exactly what option C says. ;) To quote from the summary:

classy_MAJ_MIN, e.g. classy_8_7 - a forked, stable version of classy_dev at the time 8.7.0 is released.

E)

In which case they should be marked as deprecated now while D8 is current, and convey the intention to remove them in D9. (Likewise if stable_9_2 is intended for removal in D10 that should involve a deprecration notice too.) But that would be a rather confusing message; we shouldn't advise people to opt-in to using a theme that is marked as deprecated from the outset.

E.1) I don't think we have any mechanism to "mark [themes] as deprecated".

E.2) I don't think there's any expectation from end users that the themes are going to be the same across major versions, anyway. The existing BC policy page doesn't promise that. So even if we do "deprecate" the classy_8_* themes (whatever that means), that shouldn't be a big surprise to anyone. ;)

E.3) I'd be fine with keeping classy_8_* during the entire life of D9, and have a "we deprecate 2 versions ago" style policy for these themes. So we only drop the classy_* themes for D10. That would mean we'd need to clone "classy" itself into classy_8_0 and have all the later classy_8_* themes use that as their base. That's why I'm proposing that what we call "classy" now should actually be called "classy_9_0" for the 9.0.0 release.

Thanks again for your input! Hope this clarifies.

Cheers,
-Derek

p.s. Re: Drupalisms: We've got a completely bizarre modified interpretation of semantic versioning (minor versions sometimes break APIs so we can deprecate things in time so that the next major version release is "backwards compatible" with the last minor release -- WTF?). We've got a bizarre deadlock-inducing "Front-end BC policy" that prevents us from fixing bugs. Drupal is weird, and it always has been. ;) I don't mind embracing Drupalisms if that's what it takes to make progress.

That said, I'm fine calling "stable_dev" something else:

• dev
• base_dev
• unstable
• ...

I don't really care that much.

Or, remove it entirely. But then folks who pick the "stable" road for their base theme never have a chance to get bug fixes and improvements, because we'd have no way to create stable_8_N snapshot themes. Without "stable_dev", there is no stable_MAJ_MIN, and without stable_MAJ_MIN, you never get a chance to catch up with bug fixes.

*shrug*
-Derek

Update option C to clarify "stable_dev" could easily be called "unstable" or whatever.

p.p.s. Another idea that just came to me: "stable_next" and "classy_next". Maybe less oxymoronic than "stable_dev", but still indicating it's where we're working towards the "next" official fork. Added to the list of options in the summary for option C.

@andrewmacpherson re: #52: wow, super helpful and clarifying! Thanks for writing that up, and apologies for missing your points. I definitely did not fully understand how/why stable exists in the way it does. I thought it was a slimmed/down version of the module templates and CSS, so that it had to be maintained separately from the module templates themselves. Given it was an exact snapshot of the module templates + CSS, you're absolutely right that core/modules/* is basically what I thought "stable_dev" needed to be, and therefore, "stable_dev" is not just an oxymoron, but a bad idea all around. ;) Yay!

I appreciate and share your pain as an accessibility maintainer. I didn't really mean I don't care about anything but classy. I was focusing on the way we handle classy which means we can't fix bugs in core. But yes, you're absolutely right that we need a way for live Drupal sites to benefit from these changes. That's why I'm into the (classy|stable)_MAJ_MIN forks (however they're implemented) as a mechanism to finally let sites "catch up" to our bug fixes and improvements more often that major releases.

The changes that you've helped get into core are super important, and I have great respect for that work. At the same time, they're another expression of the constant tension between "no disruption" and "we must fix this" that this whole issue is trying to address. Yes, "we" have had to make exceptions to the "no disruption" policy to fix those accessibility bugs. But it's meant potential disruption, and it's always an argument. If we had a policy that made it easy to fix bugs and easy for sites to upgrade to those fixes in a non-disruptive and bounded way, more frequently than each major release, we'd all be better off. It'd mean core development wouldn't grind to a halt unless we can call something a "major accessibility bug", and it'd mean live Drupal sites would (hopefully) see those fixes more often than every 4-5 years.

So:

• New title.
• New option D in the summary for the hybrid of option C plus your proposal for forked stable_MAJ_MIN themes at each MAJ.MIN.0-rc1 release, with a full copy of all the module templates and CSS, and no "stable_dev" nonsense. Love it.
• New patch that's basically #37 minus stable_dev. Yay.

Thanks again!
-Derek

Whoops, forgot to attach the patch.

@lauriii re: #55: Thanks for your thoughts.

If we want to stick to the current architecture, having "stable_dev" and "classy_dev" would be necessary for the Drupal 9 development to happen

Not really. "stable_dev" is silly. See #52, #53 and option D from the summary. The core module templates + CSS is already "stable_dev". We just have to fork that into newer "versions" of stable to let people catch up. classy is a different beast, which is why we need to add classy_dev here.

We should at least consider moving Classy to its own project with its own versioning.

That seems like a non-starter of a proposal. Core can't rely on something in contrib. Core has to solve this problem internally.

I believe we want totally contradictory things, hence our paralysis:

1. Don't have front end disruption for live sites. Changing markup out from under them is Bad(tm).
2. Let ourselves fix bugs and make improvements.
3. Ensure that those fixes and improvements make it into live Drupal sites.

You can't have #3 without #1. So, we've mostly stopped doing #2 (except for exceptions, see #52).

I think we have to accept the fact that we can't force markup changes onto live sites whenever we want. We have to partially embrace #1. But we need to start providing some way for our fixes and improvements to see the light of day (#3). I believe the forks of classy and stable for each MAJ.MIN.0 release is a viable compromise. It's kinda what @lauriii hopes to accomplish by moving classy out of core: let people pick the version of classy that's right for them. But we can't do that since core itself is relying on classy, and core can't have a dependency on contrib. So, we do our own versioning and "releases" from inside core.

Unless there's a substantially better solution that appears in the next week, I say we move forward here. I'd love to have classy_dev in the 8.7.x branch right now so we can start fixing the bugs in the list in the summary, and we can ship a stable_8_7 and a classy_8_7 with 8.7.0-rc1. This is not a proposal for starting to solve this in D9. This is a proposal for solving it now. We can at least start learning if this approach is viable. We can finally fix markup bugs and still have a working test suite. We'll have some means to distribute our fixes in a non-disruptive way that lets sites opt-in when they're ready to "catch up".

I really really don't want this issue to languish for a few years and die (like #2659890: [Policy] [Plan] Drupal 9 and 10 markup and CSS backwards compatibility seems to have). This is a major problem, and we have a workable (if not ideal) solution. Let's try it. Worst case, we'll learn some things that will inform how we want to approach this problem in D9. Best case, we'll decide this is a Good Enough(tm) solution going forward that we'll keep doing it in D9 and beyond.

Thanks,
-Derek

@davidhernandez re: #57:

That was suppose to be the purpose of disabling the default base theme (base theme: false.) You can do that, so you are always tracking core updates to templates, which would be in the module directories and not stable/classy.

Okay, but that's all-or-nothing. For themes that do that, they have to be watching core very closely since we can change markup and CSS in there "whenever we want". There's no way to do bounded, incremental updates. Either you're on the bleeding edge, or you're stuck at 8.0.0. I'm proposing a middle ground.

@lauriii re: #58:

We would be able to get away from this by not relying on Classy in core.

Now I'm really confused. :) Both bartik and seven use classy as their base theme. Seems like the benefit (at one point, at least) was DRY: share whatever can be shared in a common base theme. But, if that's silly, I'd be *very* happy to see classy die a quick and painless death. ;)

Testing bugs caused by markup change can be hard with limited resources since there's a big chance that the bugs only affect how the application looks visually. This heavily limits the number of people willing to upgrade.

Fair enough. But there's no way to do it at all right now, so we don't really know "the number of people willing to upgrade". We can speculate that it's going to be a low number, but we don't know.

The idea of minor-branch theme snapshots was already discussed before Drupal 8.0.0 release and we decided not to implement it given the maintenance burden and the limited benefits.

Has anything changed in our collective consciousness in the last 6+ years since this decision was made?

I'm removing some of the tags, for now, so we can try to build consensus on a proposed solution, and then invite appropriate people to review that.

Okay, fair enough. But I'm moving back to NR. There's a working patch here (that I spent quite some time on). I don't think this is "back to the drawing board" active again. You're free to not agree with the proposal, but I don't think it's fair to say there's nothing to consider here.

Finally, thanks for the link to #2352949: Deprecate using Classy as the default theme for the 'testing' profile! Apparently that's where I need to focus my energy, since that's a hopefully more viable way to unblock all the bugs I'm in deadlock on.

Cheers,
-Derek

Agreed. I'll move the child issues over to #2352949: Deprecate using Classy as the default theme for the 'testing' profile since that seems like the more viable solution to the problem of deadlocked bug fixes.

Thanks,
-Derek