We have run into a problem when updating to Unity 6, and while I believe that this is a bug in how packages are resolved, it might be something done intentionally by the graphics team.
We have a fork of URP in order to support some custom features, and our setup is this:
- Fork lives in it’s own repository, so we can version our changes
- The fork is uploaded to a scoped registry, with custom version numbers
– so if the fork is based on com.unity.render-pipelines 14.0.10, our versions are 14.0.10-rain.0, 14.0.10-rain.1, and so on - Projects reference the version from our scoped registry in the manifest file
This used to work just fine in earlier Unity versions. In Unity 6, we tried to do the same thing - we made a fork of URP 17.0.3, added the changes we want, put it on a scoped registry, added the version to the manifest file.
And Unity doesn’t care! The manifest file says 17.0.3-rain.0, the packages-lock file says the same, but the actual code downloaded is the builtin 17.0.3 no matter what. I have even tried to do very silly things, like adding a version that very obviously doesn’t work, like:
"dependencies": {
"com.unity.render-pipelines.universal": "50.1.300",
That version obviously does not exist, but Unity doesn’t care, and just silently downloads 17.0.3 anyway.
We can still use our fork, but that requires having it as an embedded package (so just copying it directly to the packages folder), but having nested repositories is a real annoyance, and since embedded packages are modifiable, it’s harder to ensure that all changes are tracked properly.
Is this just a bug in the package manager or Unity in general? Or have you decided somehow that you must be on a very specific URP version on a specific Unity version?