#24715 contains the changes to deprecate it already for 4.0.

[removed by @mbabker]

That is the nice thing about opinions. Everybody is allowed to have their own.

Developers, site owners, everybody involved will have a phase of about 2.5 years to get his code updated from 3.9 to 4.0. I expect deprecations to happen until beta and nothing after that. But from beta to release, I expect that to take about half a year, plus the 2 years that we will support 3.10 from then onward. That is enough time in my book. It actually makes me angry that you argued with the same argument of to short of a notice about this almost 2 years ago, which would have made the whole timeframe something about 4 years until people really shouldn't use 3.x anymore. I'm fed up with those discussions "Which of the 4 MVCs ("new", legacy, namespaced, fof) should I use now? I'm confused." If you want to moan about late deprecations during development, have a look at my other PRs. I'm working on removing UCM, rewriting tagging and versioning as well.

I see no reason why we should keep these classes in 4.x, especially since there are rumours that we should introduce yet another new MVC in 4.1/2/3/4/whatever as well.

[removed by @mbabker]

I just looked at https://semver.org/ and that contains no requirement to deprecate X versions before removal. It just says to bump the minor version (which we are doing with 3.10) and semver requires us to bump the major version when doing a breaking change, which we do with 4.0.

And it is a matter of calendar days. Or do you want to tell me, that if we pushed another major verison between 3.10 and what is currently known as 4.0, everything would be fine? It is always a question of real, actual time. In terms of financial investment into a site, Joomla has been pretty stable for a freakingly long time. Code from 1.6 still runs on 3.9. We also promised website owners a grace period of 2 years after the last minor release of a series to slowly get their sites switched over. You don't get such long support for a commercial Android phone. It is a reasonable transition period and the arguments for giving people longer time do not outweigh the issues of being stuck for another 5-10 years with this code for me.

And about the stemmer: Contrary to popular believe, not everything centers around the anglo-centric world. About 6 billion of us don't speak english as their first language and couldn't care less if an english-only stemmer is removed or not. The deprecation notice actually names a library that is as near a drop-in replacement for that code as I dare to propose AND which has the benefit of supporting languages for about 2 billion people. Again a trade-of that I'm happy to make.

You know, I actually had a decent reply written up, but I've decided to delete it and I'm just going to unsubscribe from the relevant PRs because all this is doing is making my blood pressure elevated, especially after the quip about being English focused (if I were really that egotistic I would have never been the one to propose the issue tracker support translations in the first place and I would've kept MAT and Sandra from doing translation support on the downloads site, just because I'm American doesn't mean I'm as narcissistic as the orange monkey residing in the White House).

Look, I have no problem with the deprecations. I don't agree with short notice deprecations without strong reasoning (i.e. security issues), and that is exactly what I think these PRs represent.

We already deprecated those classes with 3.9.0 and set removal for 5.0.
It's a very bad sign if we now change the removal date with 3.10.0. Especially since 3.10.0 is expected to be released at the same time as 4.0.0. And especially since there is no easy way to adjust the extension.
It's a sure way to piss off extension developers who relied on those classes.

And no, there are not 2.5 years to get code updated. Those 2.5 are the time people have to upgrade their site, not the time developers have to update their extensions. Those should be ready shorty after 4.0.0 is released since people will want to upgrade.

@Hackwar Still wanna leave this open after feedback as above?

yes

Maybe George should decide?

I'd like to bring this to the attention of the PLT and hear their opinions. Of course George has the final say in this.

When you discuss then please mention also the concerns Michael had and that he will block installation of the Patchtester on J4 when this is merged.

can we close this one as originally planned for 5.x ?
@Hackwar

Yes, closing this one. This wont be relevant before 5.0, unfortunately.