Add a note on tag deprecation example

[michaelKaefer]

For further info see #2696

[fabpot]

That's not really accurate. If you override the block, indeed nothing in the block will be called. But if you call parent, then you will get it. Let's close as it adds more confusion IMHO.

[michaelKaefer]

True, what would be really accurate is: If you expect your client code to override your block without ever calling your block then you should not follow the above example of deprecating a block. - I still think there should be a note to signal that it is not possible to deprecate a Twig block (it's only possible if you are lucky and your client code calls your block when overriding it).

Using this tag for deprecating a block makes no sense to me (it still makes sense for deprecating templates though):

1. If you use {% deprecated '...' %} your users who do not override the deprecated block at all (which is legitimate of course) will face a deprecation - but they should not.
2. Even worse: if client code overrides the deprecated block and doesn't call the overridden block (which is legitimate of course) the developer gets no deprecation and the app will break on the next major version of your package when you remove the deprecated block. - Here is an example of the confusion that this tag can cause: Update content.html.twig EasyCorp/EasyAdminBundle#4941

It would be nice to note that somehow to warn everybody who wants to use the deprecated tag for deprecating blocks (or the example of deprecating a block should be removed).

[fabpot]

You're right. I've just opened #3672 to remove the block example (I've replaced it with an example for macros) and added a note to warn about using deprecated for blocks.