Resolved Breaking change policies

Historically Unity advances very slowly in terms of making major changes in APIs because it seems that the important thing is to be able to upgrade a project in a version of 10 years ago to a current one (extreme case)...

The reality is that this policy severely delays making major improvements.

Ideally in any kind of software, when there is a major version, they make breaking changes (remove APIs, change APIs, etc...) and document the breaking changes in addition to an upgrade guide.

In the case of Unity it has never been like that. We have cases as curious as the "shortcuts" of the Component class that still exist despite being marked with [Obsolete] or [EditorBrowsable(EditorBrowsableState.Never)].



I remember that the fact of marking it as obsolete was back in Unity 4.0 more than 10 years ago?

Has the strategy changed or are you going to continue the same?

Thanks.

 

The answer to this has always been "we need those to stay forever because of the auto updater".

So if the answer is that again, the follow-up question is "why do you value the ability to copy-paste 10 year old scripts into Unity over the day-to-day comfort of current day developers?"

The people who copy-paste scripts with .rigidbody into their projects are either total beginners, who should be looking at more up-to-date tutorials, or people with some experience that can figure out a simple API conversion themselves. For large projects, updating from Unity 5.6 to Unity 2024 by opening in Unity 2023 or some other version that's got the properties deprecated won't be a too large problem.

 

I would love a policy like “every yearly version is unbound from the previous”, with a detailed upgrade guide on the documentation page. The way I see it that would gel really well with the LTS culture, where 2023.3 keeps junk and 2024.1 declutters, something that Unity packages already seem to be doing with every major release anyway.

To say something about asset store assets: if I buy code, I already check if their latest release was less than a year ago (and support page helps too) if it’s something high-level, and Unity has the power to put pressure on developers there as well, by having each new asset release going through an automated system checking if it works on each currently supported unity release, or by warning buyers when the latest asset release has NOT been checked by a new unity release.

If that’s too extreme than at least make it follow the LTS pattern where 2 years down the line the API becomes unsupported. Once you sign up for a life of coding, you have already accepted that you’ll never stop adopting new features.

And if you need suggestions, I’d love to see Unity start treating “null” components as “null”, I’d love to see nullable implemented, and a lot of people seem in favor of Span (though to tell you the truth I still have no idea how to use it properly).

 

One way to improve code version is to have asset become downloaded as UPM package format and enforce git structure. And ability to put dependency on package from any person

Imagine that we can have some old asset that was discontinued. We just try to upgrade it into latest version by changing obsolete codes in 2-3 files. We can add 2 cents to our package but make it depend on the original. So people who already bought original package can buy our package with 2 cent and the useful package will got upgraded while giving the original creator all of what they deserved