[policy, no patch] How to handle Drupal 8.9.x deprecations

I think there are tradeoffs in all directions. I think potentially option 1 with a commitment to only do deprecations in 8.9.x and 9.0.x when the benefits are large.

For example I see little benefit at this point to emitting a deprecation in #3087975: Add deprecation to InfoParserDynamic::__construct() to require root path until 9.1.x or even later (other than having it done).

I lean towards option 2 for the PMs sake, maybe with the caveat that when deprecating something you should post a patch with the suppression removed to prove you got them all, along with a RTBC issue similar to the vendor min max testing issues that runs with the suppression off to catch any accidental reintroduction of deprecated code.

Symfony 4 introduced a lot of deprecations that we can't fix in core until we are actually on symfony 4 that are currently suppressed. I would like to have the suppressions removed before 9.0 release, but that will likely mean having some bc layers in there triggering errors.

It will affect contrib - see http://grep.xnddx.ru/search?text=InfoParser&filename= (InfoParser extends InfoParserDynamic)

I think there's a couple missing options -- for example, don't commit any new deprecations until 9.1.x opens for development in a few months (maybe with @todos for important deprecations now). The disadvantages of that are obvious, but it means way less noise in automated tests and static analysis tooling for the major version upgrade, no PHPStorm noise, no branch divergence, and a nice shiny and new 9.0.x. I'm still leaning toward that approach, if only for 8.9/9.0. We could potentially do something like option 2 for 9.4/10.0.

FWIW I do think there's also some advantage in having some amount of restriction on what's committed for a few months. We've been at full-throttle new feature and API development for going on 5 years now. The criticals queue is out of control, etc. For me slowing that down a little and focusing on the stability of 8.9/9.0 for a few would be valuable. Obviously blocking major/critical bugfixes isn't in our interest though, so those would add technical debt and a task we would need to do for 9.1.x.

The cleanup task could be a single issue though, like:

 * @todo Deprecated in drupal:8.9.x and will be removed before 10.0.0. Use 
 *   fooBarMethod() instead.
 * @todo Finalize the deprecation in https://www.drupal.org/followup-issue.

    // @trigger_error('Deprecated in drupal:8.9.x and will be removed before 10.0.0. Use fooBarMethod() instead. See https://change-record-here');

Replaced with:

 * @deprecated in drupal:8.9.x and will be removed before 10.0.0. Use
 *   fooBarMethod() instead.

    @trigger_error('Deprecated in drupal:8.9.x and will be removed before 10.0.0. Use fooBarMethod() instead. See https://change-record-here');

Edit: Fewer code snippet syntax errors.

As one of the many people involved in the gargantuan task of cleaning up after all the improperly deprecated things in the early D8 cycle, I can't say I'm a fan of doing commented out deprecation errors. Not only are @todo's and cleanup follow-ups notoriously never gotten around to, but during the time the error is commented out, it is quite possible to commit new code using the deprecated code path, that won't be caught until we go to try to uncomment the error. (I'm still suffering PTSD from format_string, and last I saw Berdir, he was curled up in the fetal position mumbling something about entity_manager)

I of course realize there are other considerations here, and 4 months of technical debt around deprecations is a far cry from 4 years. I wish we had a slightly different workflow that allowed us a master branch that we could push the final deprecation to at the same time we commit to 8.9/9.0 just to avoid all the @todos and postponed issues.

I also do agree that spending a release cycle on stability will be beneficial. Maybe trying for Symfony 5 compatibility when 9.0 is released isn't worth the disruption, maybe that should be targeted for 9.1.

allowed us a master branch that we could push the final deprecation to at the same time we commit to 8.9/9.0 just to avoid all the @todos and postponed issues.

I've made similar arguments before in discussion with @catch. The problem being that this increases the branch management workload on committers. It'd be a bit better it we used a merge workflow.

With option 6 and 5, what's to stop us committing to 9.1 immediately, other than the workload of having 4 active branches (8.8, 8.9, 9.0, 9.1) and a fifth with security support (8.7)? Would that address your concerns @mikelutz

#3074585: [Symfony 5] Replace app.root and site.path string services with container parameters is an example of a deprecation we will want to make in either 8.9 or 9.0 for removal in Drupal 10. The app.root and site.path services as strings are deprecated in Symfony 4, and while the deprecation errors are currently suppressed, it's generating a lot of them and is causing us to disable apcu during the Javascript Install test because of some conflict and bug in php. We will definitely want to have that test back using apcu and remove our use of the string services internally by 9.0-beta.

So if we go the 6 or 7 (or even 2) route, we would create the new services, stop using the old ones in 9.0, but one way or another not trigger deprecation errors on them until 9.1 (either next spring or immediately) The concern with #6 is that we could introduce new code using the old services and not catch it in a test. With #7 we could potentially catch it in a test against 9.1 assuming one gets queues, in the other ones we might not catch it until we do a followup.

There are definitely trade-offs any way we go. I'm just trying to give a concrete example we can think through.

I marked #3073936: [policy, no patch] Policy for Drupal 10 deprecations as a duplicate of this issue.

+1 to #20 as a general policy. I'm wondering how to apply it in #3074585-46: [Symfony 5] Replace app.root and site.path string services with container parameters.

This was announced in https://groups.drupal.org/node/535670, should we close the issue or keep it open for tracking / re-evaluation later?