Frustrating frivolous API changes

Please stop making unnecessary, frivolous API changes. It's maddening.

This time, it was

error CS0143: The class `UnityEngine.Video.VideoClip' has no constructors defined
error CS0122: `UnityEngine.Texture.Texture()' is inaccessible due to its protection level

and I find that those have suddenly been changed to protected, which makes no sense. These constructors did exactly what I needed: in error scenarios, if a texture or video resource was missing, my loader logged a warning and created a dummy VideoClip or Texture to return to the caller. That way, the caller always gets an object, not null or an exception, so it doesn't have any special cases for rare error conditions. The missing resource simply doesn't display, and the game recovers with an isolated asset error. It worked exactly as intended, isolating error handling and minimizing the code surface area for dealing with rare errors.

Working around Texture is easy enough (replace it with a dummy Texture2D(1,1)), but there's no equivalent for a dummy stand-in VideoClip, so now I have to spend time putting a placeholder fallback video to load.

None of this makes my game better. It's just pointless busywork. Every time you do this, you discourage everyone from ever upgrading Unity. Please stop breaking everyone's code.

 

I understand your frustration. But I expect Unity doesn‘t make these changes without a good reason. Here I would say that hiding the constructors falls in line with general Unity practises of not providing default constructors for many objects since you normally use already instanced objects or methods like Instantiate.

When updating, you have to expect some extra work to fix issues but mainly testing that everything still works as it did, there may be side-effects or new bugs for instance. You can be happy it‘s just API changes that cause compile errors that are easy to pin down.

The real question here is: if it causes you this extra work that you don‘t want to put in, why did you upgrade in the first place? Unless you are in need of the update (new feature or bugfix you have to rely on) it is best practise to just keep using the current Unity version, depending on how close you are to releasing and how many other developers might be affected by the update (ie the LTS branch exists primarily for enterprise customers who rarely upgrade throughout a project‘s lifecycle).

 

I updated because I wanted to see if a bunch of VideoPlayer bugs were fixed. But it doesn't matter why you're updating. You shouldn't have to work around a bunch of unnecessary breaking API changes in order to update.

Unity makes changes without good reason all the time. They even changed "Camera.hdr" to "Camera.allowHDR", which is an unnecessary cosmetic change that just gives every library maintainer headaches. "But it's clearer!" It doesn't matter. A slightly clearer name doesn't make up for breaking an API that's already in use. Design your API and stick with it. Don't go back and tweak and modify it constantly once it's been released and thousands of people are using it. If you make a mistake, learn from it and design your next API better. This is a basic API design principle.

This seems like a cultural problem within Unity. They seem to think it's normal to just constantly break APIs that people are using. It's not. This is also why I will probably never release another script asset on the store: after you release anything, you have to babysit it for the rest of your life, since Unity is a moving target.

 

I disagree. If you favor code rot over clean API in the long run you will have people moving away from the product as it becomes less and less consistent. Even internally developers will care less and less. This is a sure way to let quality
rot in the company culture too.

A seemingly ‚random’ change like allowHDR make me think they actually care about their product. Of course these changes can be annoying, but Unity upgrades aren‘t particularly time consuming in my experience. And like I said, if this is an issue for you stay with the LTS versions and don‘t use any features that haven’t been available for at least a year. Choose your tradeoff.

Of course I have been in a situation where we upgraded but ran into a bug, couldn‘t downgrade anymore due to relying on a newer feature and being locked into waiting for the bugfix that took two months before we could continue work on the GUI. But this isn‘t just Unity‘s fault, we were also too confident to use a new GUI feature replacing the existing system without properly testing it. Lesson learned.

As for Asset Store developers you just have to be on top of the game, testing your product with betas even. This is what I‘m paying for in the Store, and it‘s the same reason I have much less trust in cheap or free assets. I‘ve been telling that my coworkers who thought about publishing their own stuff to not underestimate the amount of support and bugfixing you will be asked for.

 

Is what @SteffenItterheim said. But to add, no one is forcing anyone, to use latest, or different version of Unity. In the end you should have a copy, before migrating to new version. Just in case.

I prefer smaller changes steps when migrating between version to version, rather having one huge blob of errors, not knowing, how to bite it, to begin with. That assuming we want modern and more efficient tech.

Thing is, editor software in programming is completely different approach than any other type of applications. Lets consider documents, word, excel. You have some formats which emerged over time, some less or more backwards compatible, but core format is almost the same. And is hard to break them with the editors.

In media, videos and audio file follow similar patter. Often having new formats, incompatible with previous versions. But again, you are likely to not break files itself. Or you will notice strait away during developemnt.

Either way, in both cases changing GUI behavior, or software core, rarely breaks the files format itself at release.

While, where you have programming editor, you scripts/assets are strictly connected with the core. Anything changes there, is likely affect your scripts/assets, as their are tightly linked. So as the result, if you want modernize application, you are likely run into cases, where written scripts, wont be compatible without explicit update to new version.

But yet, we don't want stay in stone age. Or are we?