Search Unity

  1. Unity 2019.4 has been released.
    Dismiss Notice
  2. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice
  3. Ever participated in one our Game Jams? Want pointers on your project? Our Evangelists will be available on Friday to give feedback. Come share your games with us!
    Dismiss Notice

Please stop with your madness, SRP updates should be sync'd to Unity releases

Discussion in 'Universal Render Pipeline' started by jbooth, Apr 16, 2020.

  1. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,252
    Currently, if you download a Unity 2019.3 version and choose a URP project, it may install:

    URP 7.1.6
    URP 7.1.8
    URP 7.2.1
    URP 7.3

    This will depend on which patch release you're on. A PATCH RELEASE, not a Unity version. 3 of these have breaking changes in the shaders that make them incompatible with the other versions. You also can't downgrade to, say, 7.2.1 on the latest Unity, or upgrade to 7.3 on the older versions.

    It is impossible to maintain compatibility with these changes:

    - You don't document the changes, or any of the shader code
    - You release these at seemly random moments
    - There is no Unity 2019 version of the SRP that anyone can count on actually working
    - Different assets are going to be written for each one, because it's impossible to support them all. So now any two things on the store won't be compatible with each other.
    - People don't understand this when they buy assets, because Unity used to "Just Work", now, it "Just Breaks".

    So fine, you might write a shader abstraction layer one day to deal with this, which you should have done from the start- given the glacial pace of Unity fixing things vs. breaking things, that's at least a year or two off. In the mean time, can you please limit breaking changes to align with Unity version changes? Not patch releases? Patch releases are supposed to fix things, not break them, or make it impossible to support your pipeline.

    You've gone over the cliff of insanity at this point- can you dial it back just a hair?
     
    SugoiDev, Meceka, Olmi and 1 other person like this.
  2. Tim-C

    Tim-C

    Unity Technologies

    Joined:
    Feb 6, 2010
    Posts:
    2,154
    Hi Jason,

    We have been massively building out our internal test farm over the few weeks to try and catch API breaking issues before they can reach asset publishers (C# as well as shader side). Would you allow us to include a version of your package in our automated farm to protect against backwards compatibility breaking? We are going to be trying to get a number of asset store publishers into this mix as well.
     
  3. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    4,252
    Absofrequinlootly..

    So is the idea that breaking changes are NOT supposed to happen during unity patch cycles? Right now I feel trust being eroded all around by these types of issues, and it would be good to understand what your intension is with releases, so that it's possible for us to know what we should expect. Right now my expectation is that every release of an SRP may change or break anything, and if that is not the case, it would help me understand both how to support the pipelines as well as how to direct users when they find issues.
     
  4. Tim-C

    Tim-C

    Unity Technologies

    Joined:
    Feb 6, 2010
    Posts:
    2,154
    Expectation is that we should be using semvar properly.
    Major Release - We may add, break, or remove API - We will try not to but it can happen
    Minor Release - We may add api but not break or remove API
    Patch Release - Should generally only be bug fixes. Rarely add API, not break or remove API

    I'll contact you get get a setup that we can work with from you.
     
    Rich_A likes this.
unityunity