Search Unity

  1. 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

Semantic versioning like 1.0.x is not working

Discussion in 'Package Manager' started by arielsan, Mar 24, 2019.

  1. arielsan

    arielsan

    Joined:
    Dec 3, 2013
    Posts:
    42
    Hi, I was testing semantic versioning (semver calculator) to depend on latest patch of a specific version but can't make it work. I supposed it was supported by reading the forums and even by the error code:

    Code (txt):
    1. An error occurred while resolving packages:
    2.   Project has invalid dependencies:
    3.     com.unity.collab-proxy: Version '1.2.x' is invalid. Expected one of: a 'SemVer' compatible value; a value starting with 'file:'; a Git URL starting with 'git:' or 'git+', or ending with '.git'.
    4.  
    Am I doing it wrong? is it not supported yet?

    Thanks!
     
    Last edited: Mar 25, 2019
  2. JakHussain

    JakHussain

    Joined:
    Oct 20, 2016
    Posts:
    316
    I'm pretty sure all 3 digits need to be numbers. You can also add "-preview" at the end of the version number for the preview tag to appear in the package manager UI.
     
  3. okcompute_unity

    okcompute_unity

    Unity Technologies

    Joined:
    Jan 16, 2017
    Posts:
    729
    Hi @arielsan ,

    Semantic Versioning (SemVer) is at the core of the Unity Package Manager. But, what you are trying to set is called version range. It refers to SemVer versions. Two related but different concepts. Version range is not supported for the moment by Unity Package Manager. This is in our long term plan though. Note that we plan to implement a Nuget (or Scientific) notation. This is different than npm implementation.

    Hope it helps,

    Pascal
     
    mandisaw and JakHussain like this.
  4. arielsan

    arielsan

    Joined:
    Dec 3, 2013
    Posts:
    42
    Yes, it helps, and clarifies the concepts :), sorry I was messing them up.

    We'll have to wait until version range is supported then :(

    Thanks!
     
  5. JKort

    JKort

    Joined:
    Sep 14, 2017
    Posts:
    1
    Any update on this? Also wondering why to opt for the nuget implementation when everything else seems to be based on npm packages. Personally think the npm ranges are easier to read as well :)
     
  6. mandisaw

    mandisaw

    Joined:
    Jan 4, 2018
    Posts:
    43
    Just a guess, but probably because .NET/Visual Studio already understands NuGet.
     
  7. Florian-Nouviale

    Florian-Nouviale

    Joined:
    Mar 14, 2013
    Posts:
    29
    Hi, any news on this ? It's difficult for us to maintain CI generated dependencies automatically without version range
     
  8. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    203
    Nuget interval ranges are already implemented in Unity in the Assembly Definition inspector (see Version Defines). It didn't seem to make sense to implement the same concept with two different notations in two related contexts.

    We might possibly support a limited set of npm range operators, but probably not the full notation; npm range syntax allows defining arbitrarily complex, non-continuous version ranges (e.g.
    ^1.0.0 || 2.1.4 || (> 2.4.0 <=3.0.0) 
    is a valid range in that notation), but continuous version ranges are actually a characteristic on which the package manager depends to resolve dependencies efficiently.

    Lastly, on a more technical aspect, the notation "X.Y.Z" is actually supported in the Nuget notation as a shortform for the range starting at version X.Y.Z (inclusive), with no upper bound. Compare with "X.Y.Z" in the npm range syntax, which represents a range containing _only_ version X.Y.Z, and nothing else. That means changing the semantics of the dependency version notation while keeping backward-compatibility for all existing packages would be problematic (although not impossible, for sure). On the other hand, using the Nuget notation just means keeping the current interpretation of X.Y.Z and adding support for new forms.
     
  9. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    203
    There's currently no ETA for this feature yet. The range notation we intend to support will allow packages to specify explicit ranges in order to let the Package Manager avoid choosing incompatible combinations (i.e. conflict resolution) but will not have the effect of making the Package Manager pick a higher version.

    @Florian-Nouviale I will make an educated guess that your scenario involves CI-triggered tests using the latest dependency versions to continuously assess compatibility. Am I correct? In that case, what you could use is the "resolutionStrategy" property in your project manifest.json. It's not yet publicly documented (this is about to change), but it works similarly to Nuget's dependencyVersion property (see https://docs.microsoft.com/en-us/nuget/release-notes/nuget-2.8#-dependencyversion-switch). The supported values are "lowest" (default), "highestPatch", "highestMinor" and "highest".

    For example, to ask the Package Manager to upgrade transitive dependencies to the highest compatible minor versions:

    Code (CSharp):
    1. // manifest.json
    2. {
    3.   "dependencies" {
    4.     ...
    5.   },
    6.   "resolutionStrategy": "higherMinor"
    7. }
    Note that this only affects transitive dependencies for now, so your CI would still need to generate/update your test projects' manifest.json files with the highest versions of the direct dependencies you need to test.
     
unityunity