Recommended approach to handle multiple release versions of custom package on git

Hi @Xarbrough !

Let me recap:
You already have a package xyz@1.0.0 that is compatible with Unity 2018.3
You want to make it compatible in 2019.1 because their's some API changes in Unity

So, you need to create a new version your package and mark it compatible with 2019.1 (minimum version)

The best approach for you will be to have to separate branches in your repo (one for 2018.3 and one for 2019.1) in case you need to publish a patch version (bug fixes for 2018.3, in case you need to publish xyz@1.0.1)

Regards,

Manu

 

@Xarbrough

I recommend you to only increase minor version. It will let you space for possible patches.
For 2018.3: x.y.z@1.0.0 (so you will have space for possible patch versions 1.0.1... 1.0.nnn)
For 2019.1: x.y.z@1.1.0 (so you will have space for possible patch versions 1.1.1... 1.1.nnn)

Of course, if your public APIs need to be updated because of changes required, you need to use x.y.z@2.0.0 to clearly identify API break (See https://semver.org/)

Regards,

Manu

 

@Xarbrough,

I'd like to offer different guidance on the topic. While the suggestion made by my colleague @manu73 would certainly work, it's not really aligned with semantic versioning, and it could lead you into a corner where you would need to make a decision among bad choices. For instance, if you were to use different versions for 2018.X and 2019.X, but you wanted to implement a new feature for both Editor versions, you'd have to lie in the 2018.X versioning by slipping a feature inside a patch version. (Note that your suggestion of using different major versions alleviates this somewhat, but you're still stuck if you need to make a breaking change in your 2018.X-compatible API...)

As mentioned by @Favo-Yang a superior approach is actually to leverage Unity's #if UNITY_X_Y_OR_NEWER, so that a single package works across multiple versions. Why? Well, it's simpler for you (no forking or versioning hell induced by Unity versions, no backporting or unnecessary branching), and it's simpler for consumers (more consistent feature-set, less likely to need explicitly changing dependencies when switching Unity versions, and it makes your package easier to use as a dependency in other packages).

Going back to your initial question, which addressed using Git as a delivery method. In that case, you can certainly ignore the above advice if your users only use Git URLs with branches, but as soon as you want to follow a more Semver-esque strategy (including if you want to ship versions of your package through a registry), I would strongly recommend keeping a single codebase, with as few #if as needed to keep your code maintainable.

 

Note that the above was meant in a general manner. In your case, where you use Git as the delivery mechanism, your package cannot be referenced as a dependency in another package because that's not (yet) supported. If you used a scoped registry, however, there would be no such limitation.