I know we do not have a deprecation policy for strings. But deprecations are here to give developers time to adapt their code. If we deprecate something in 4.4 and remove it in 5.0, then it doesn't make sense as both are released at the same time. So I would target this pr for 6.0.

in which case then you might as well close this and related pr

The pr's itself are fine, just want to point out that it is hard to understand for 3rd party extension devs, when it gets basically removed at the same time when deprecated.

I'm fine with deleting the strings in 5.0, I see no problem with deleting language string in a component which actually doesn't have any b/c coverage, means you still have 2 years for migration. in opposite we couldn't do any deprecation in 4.4 because the also get removed in 2 years.

I would suggest to wait for the planed b/c policy meeting (if it comes soon) and decide then.

FYI I would have just deleted them without even marking them as deprecated as they are component strings that have not been used for a long long time

I have more a problem with the short deprecation timeframe and not with the removal itself.

2 years is too short?

I'm talking about the release time of 4.4 and 5.0 and not about how long is 4.4 supported.

@laoneo if this was code and that code was being used then I would agree 100%. If this was in a library or generic language file then I would agree 100%. But this is in a component.

Also marking a string as deprecated is a pointless thing to do anyway (even though I have done it as requested) as unlike a deprecation note in code it is never logged or displayed.

Finally some of the extra strings that we have might have been unused for ten plus years. A Previous maintainer refused to allow a string to be removed, ever, and no one thought to compromise with him by marking them as deprecated

@brianteeman Can you please update this PR?