Why are packages tied to Unity-version patches?

Unity Engine
,
1

I frequently see packages that have their Unity versions set to specific, non-zero patch versions. For example, the current latest version of the Unity.Collections package has a Unity version of 2020.3.17f1. That means that if you are on an earlier version of 2020.3, it will not show up in the package manager. However, if you manually modify the manifest file for the project to use version 1.2 of the collections package, it works fine since there are no api changes between, say, 2020.3.10 and 2020.3.17.

It would make sense if a package required apis that only exists in, say, 2021.2, to target that specific version and above, but why are packages targeting non-zero patch versions if there are no api changes? As far as I can tell, it’s never specified if there is an explicit reason for that specific version, so it’s unclear if it’s okay to use a version that doesn’t show up in the package manager by modifying the manifest file.

I would appreciate if someone could provide some clarity on this.

1 Like
2

I would assume that earlier versions may have bugs that affect the package, or the package was simply not tested with earlier versions and so there „may be“ bugs affecting the package, or not. In any case it should be (relatively) safe for users to upgrade Unity editor to the latest minor version patch level.

3

I also wish packages could be more Unity version agnostic,

However, the more common reason is due to API specific changes. Features that are designed in a certain way utilizing certain API calls that do not exist in previous versions.

Another reason may be as Steffen mentioned, bugs that may not be fixed in previous versions.