When Unity is going to remove obsolete properties from Component class?

They are there and marked as obsolete from Unity 5 and always get in the way. They make refactoring tools to make mistake and make clutter in auto completion.
When Unity is going to remove them?

 

They aren't likely to be removed for a long time; the idea is that when you update to a new version with old scripts that still use those obsolete methods, you get a warning that they're obsolete with (generally) a description of what you should be doing instead. This way, you don't just get a compiler error that doesn't necessarily indicate why the script in question is breaking when it previously worked.

 

I see.
But it's been so many years since they have become obsolete. What are the chances that someone wants to use a script from Unity 4 inside Unity 2019?
Even if someone is crazy enough to upgrade a Unity 4 project straight to Unity 2019, they can search google or ask on forums on how to upgrade. or even use a lower version first.
Leaving those API there benefits very few people but actually clutters the environment for every Unity developer.

 

It happens all the time with people using old tutorials and such (including some of Unity's own). It's the problem with a public API, you can't just make breaking changes like straight up removing classes and methods. It'd be nice if we could expect people to research the errors that result from breaking changes and fix them appropriately, but that's a little much to expect from the many new developers that Unity attracts.

My personal opinion is that your complaint is valid (though I haven't run into the issues you're having), but I'd imagine Unity has a strong interest in not scaring off new developers.

 

I don't understand what you mean by they are in the way. Just don't use them.

Unity doesn't generally remove deprecated or obsolete API's until they prevent future feature development. So when development of a feature is hindered by these old API's then they will be removed. Until then they are just left to rot, and probably don't get a lot of QA regression testing.

There's a lot of benefit for small time developers leaving them in, because often those people are running a good amount of 3rd party code from assets, old forum posts, etc, which solves a problem for them which they may not fully understand. Removing these API's then hinders these developers by breaking code which they didn't write, now making them update that code themselves or take a risk updating to a later version of the asset.

For example in my game I've got a water system which was deprecated on the store back in the 5.x days, but I've done a little self support to get it to work in 2018.2.x. It is currently screaming every time I recompile about around 30 instances of obsolete API use. I'm really not looking forward to having to rewrite all that myself, since the reason I bought a water asset is because complex shaders is a definite weak point in my skill set.

 

So true... Google still sometimes offers up Javascript-coded results in response to certain Unity questions, and JS/UnityScript has been deprecated for a few years now. Plus there are tons of open source repositories of Unity stuff that are simply far out of date in every possible way: API, language, best practices, etc.