Search Unity

Question Why is the UGUI version number always 1.0.0?

Discussion in 'UGUI & TextMesh Pro' started by SebastianBitwave, Nov 23, 2022.

  1. SebastianBitwave

    SebastianBitwave

    Joined:
    Jul 8, 2022
    Posts:
    13
    Hello! I searched the forums and could not find this answered anywhere. Why is UGUI's version number always 1.0.0 even though it appears to be updated every other Unity version? We noticed this because we have made modifications to the package in our project and got very confused when we updated Unity version and all sorts of stuff in the package broke.
     
  2. SimonDarksideJ

    SimonDarksideJ

    Joined:
    Jul 3, 2012
    Posts:
    1,689
    I think the simple answer is that from 2019.1 Unity stopped publishing the Unity UI to OpenSource as a copy, we can only assume that this meant they stopped active development from 2019 (when it was first published) and then focused on the newer UI Builder.

    The version in source is definitely not what is in the product today, as Unity have been doing internal updates in line with engine updates.

    You should NOT be making changes to the original package as it has changed, more rather write your own components BASED upon theirs (if you need to inherit) or copied from source and named for your project.

    Effectively Unity UI is "deprecated" in all meaningful sense of the word and the new word is UI Builder.

    As to why they don't change the version number? Likely because there are there are no structural changes and it's not an upversion, and updates are maintenance only. (mainly good guess work from Unity's history with UI)
     
    SebastianBitwave likes this.
  3. SebastianBitwave

    SebastianBitwave

    Joined:
    Jul 8, 2022
    Posts:
    13
    Hey Simon, thanks for the reply.

    We're not basing it off the repository, rather we've copy-pasted the package from the package cache and embedded it. It's not exactly relevant to the question asked but just as an explanation as to why went the route of modifying the package rather than inheriting was because the project 1) is a couple of years into development and replacing components with a subclass would be a lot of prefab work 2) our changes are minor but hard to recreate through subclasses. F.ex. we've added the concept of auto-navigation groups (just an integer on each selectable) where only those within the same group can auto-navigate to each other.

    All that to say, even a non-interface breaking maintenance change to the package should obviously up the patch number, add to the changelog etc. according to Unity's own recommended package workflow. It doesn't really matter to us one way or the other, but it's an oddity that made me curious as to what the reasoning behind it might be.