Problem/Motivation
#2670360: Add BC layer in installSchema to support url_alias adds a BC layer which should be removed before 8.1.0
Proposed resolution
Remove it
Deprecate it.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | 2670454-22.patch | 6.19 KB | lendude |
| #21 | interdiff-2670454-19-22.txt | 3 KB | lendude |
| #19 | 2670454-19.patch | 2.12 KB | lendude |
| #19 | interdiff-2670454-13-19.txt | 1.89 KB | lendude |
| #13 | 2670454-13.patch | 926 bytes | daffie |
Comments
Comment #2
dawehner.
Comment #3
catchProbably best time to do this would be after the last non-security patch release for 8.0.x - then apart from last minute security release which won't have advance testing with contrib anyway, we know we're not introducing any more changes into the branch then.
Comment #4
tstoecklerCan someone explain why this is tagged against 8.1 instead of 9 ?
I.e. will this not cause a module's tests to fail again when run against both 8.0.0 and 8.1.0 ?
Comment #5
catch@tstoeckler once 8.0.x support is dropped, there'll be no tests that actually need to install those system tables, so an updated module's tests will pass - because they'll only run against 8.1.x (or 8.1.x and 8.2.x by that point).
A module that hasn't been updated will have failing tests, but we explicitly let ourselves break tests between minor releases. This one was annoying though because a test that passed on both branches was tricky to write (if at all).
Comment #6
tstoecklerAhh so, the day that 8.1.0 is released 8.0.* is unsupported? I wasn't aware of that. Thanks for the explanation.
Comment #7
catchYep, see https://groups.drupal.org/node/508968 and https://www.drupal.org/core/release-cycle-overview
Comment #8
tstoecklerThanks!
Comment #13
daffie commentedSupport for Drupal 8.0.x has been dropped, so lets do this.
Comment #17
mile23Patch in #13 still applies. Restarting test.
Comment #18
alexpottI think we should add an
@trigger_error()and deprecate this. That way we can fix core but not break contrib tests. And then once we allow contrib tests to define whether they should skip deprecations or not they can benefit from this info too.Comment #19
lendudeSo something like this maybe.
Comment #21
lendudeWell that shows the deprecation works.
Took out the remaining fails (I think).
Comment #22
borisson_Yep, the test is green, so that means that you've caught them all.
Comment #23
catchCommitted c16c5d0 and pushed to 8.7.x. Thanks!
Comment #25
larowlanShouldn't the deprecation notices link to a change record?
Comment #26
jibrans/invalid/individual
Comment #27
berdirAlso, the @deprecated on the docblock marks *all cases* of this method as deprecated/striked-through in PHPStorm. Maybe only use that if the whole method is deprecated and document this in a different way?
Comment #28
alexpott@jibran the work invalid here is correct.
It reflects the fact that this did not cause an error.
sequenceis an invalid name.Comment #29
alexpottAdded a change record for what it worth - https://www.drupal.org/project/drupal/issues/2794347
I agree with @Berdir - we should remove the @deprecation from the method since it is only a BC behaviour of the method that has been deprecated. Let's do that in a follow-up.
Comment #30
alexpottOpened #3003361: Fix deprecation notice for 2670454