Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice
  3. Dismiss Notice

Please consider backporting ASMREF, optional reference, use GUID, and conditional reference!

Discussion in '2019.2 Beta' started by 5argon, Jul 6, 2019.

  1. 5argon

    5argon

    Joined:
    Jun 10, 2013
    Posts:
    1,556
    I know it is against the policy to backport a features and not fixes, but I think these worths an exception the same way Android 64-bit build was backported.

    Why? Because this is the backport of backports. It will allow UPM package ecosystem to florish long way into the future.

    - Optional dependency : that arrives in 2019.1 is already enough bad timing that it missed 2018.4 LTS version for a year to come. Timeline became a package in 2019.1. UGUI became a package in 2019.3. I then face a dilemma that is if I put that properly in my asmdef, and 2018.4 user use my asset, they get an error instead of greyed out Timeline and UGUI. The package would be usable perfectly otherwise because Timeline and UGUI are built-in over there.

    - Use GUID : Meta files comes together with purchased Asset Store items, this will allows package publisher to freely rename their assembly without fearing about breaking the world. It is important in things like serialization where fully qualified name my also be stored.

    - Conditional reference : This is fantastic to allow add-on features, and more importantly proper collaboration between multiple publisher. (therefore may drive even more Asset Store purchase, to say in terms of Unity's incentive) If this is not backported, I would be hesitated to add package linking because I don't want my user to manually define a project-wide directive. (It is already difficult to explain that in the manual) And directive appearing automatically based on some editor script magic is honestly annoying and dirty. (Like TextMeshPro and UNITY_POST_PROCESSING_STACK_V2) I already want to use the Burst and Collections package in my asset to make things awesome, but I fear that 2018.4 LTS user will face errors.

    - asmref : I guess this make separate folders able to be together in the same assembly? This is not as important as others but obviously nice to have. Also if this means I could sell 2 separated assets that ended up merging into a single assembly, it would add potential to make more flexible Asset Store items.

    Currently the adoption is already low enough. You just don't see Asset Store publisher even putting .asmdef in the project, even before you can see package.json adoption in the asset folder. Even if they know how to do it properly they have to additionally fear about dropping support for a bunch of versions under 2019.1 / 2019.2, that they are better not doing it at all. If you make these backports it will unlocks so many potential for everyone. (Asset Store or on GitHub) And I believe this will help Unity able to position as the more open game engine with vibrant community, where everyone could share code easily and help each other. Thank you.