Thanks for the great explanation and for pointing out the R3 Unity package.

I’ve been reading through the Unity documentation about the Package Manager (there have been substantial improvements since the last time we looked at this), and I’m a bit disappointed with how the Git integration works. I was expecting Unity to ping the given address to check for new updates, so users could receive notifications when a new version becomes available. From what I understand, this seems to be supported through scoped registries, but not through Git-based packages.

So, if Git doesn’t support that workflow, how does the current situation compare to the proposal using Git? As a Noesis licensee, you already have access to a private folder containing all our Unity releases (packages as ZIP files) that you can download and organize however you want.

Instead of offering a Google Drive space, we could move this to Git, but in the end the result seems quite similar. You still need to manually go to our folder/repository, grab a version, and move it into your system.

Am I understanding this correctly?

> As a Noesis licensee, you already have access to a private folder containing all our Unity releases (packages as ZIP files) that you can download and organize however you want.

Oh this was news to me, I thought it was enterprise only or some special case. I just sent an email for access, thanks for bringing this to my attention!

> I was expecting Unity to ping the given address to check for new updates, so users could receive notifications when a new version becomes available.

I'm not sure I understand this part. Did you want like a dropdown in the UPM ui inside of Unity where people can pick from versions instead of updating the manifest pin manually? If you use the "default" then there isn't really any ping it just checks if there is a newer commit and if there is, it will automatically use it. Notifications for people who are version pinned would probably still go out over email etc. Very sorry again if I am misunderstanding.

> but in the end the result seems quite similar. You still need to manually go to our folder/repository, grab a version, and move it into your system. Am I understanding this correctly?

Not really, no. Most of the time I am just popping a git repo address (private or public, depending on the UPM source) straight into UPM and it grabs everything for me automatically to make sure I have the latest. Some third-party assets have a small detection helper that lets me know about an update, Rider IDE's bridge package is a semi-official example I guess where they have some subtle hints about a new version in logs and a few other places.

If I notice a new version is out, I can manually repin in the manifest. I'm not sure the UI in unity offers a dropdown when using a git repo like you get for some of the official plugins, but if this is a must have I can look into it more. Usually I just manually edit the file to have the right version and unity reloads, but if you have it pinned to latest I don't think you even have to click an update button it just automatically updates. I'd have to triple check to confirm this part though.

You can even have the package on a specific "UPM" branch and the main contains the project that generates it, for convenience, etc. It's pretty flexible.

In case it's handy, an example template with some explanations:
https://github.com/adrenak/upm-template

I'm not sure I understand this part. Did you want like a dropdown in the UPM ui inside of Unity where people can pick from versions instead of updating the manifest pin manually? If you use the "default" then there isn't really any ping it just checks if there is a newer commit and if there is, it will automatically use it. Notifications for people who are version pinned would probably still go out over email etc. Very sorry again if I am misunderstanding.

In the Package Manager, there is a section for updates where new versions are shown. Unity periodically pings registries and retrieves this information.

As far as I understand, packages installed from a Git URL don’t do this. So when you want to update a Git package, you need to check the latest version available in the repository and then manually update it.

This isn’t very different from our current solution, where you have a list of ZIP files for each version, and you can download the one you need and place it in your project. Ideally, it could be a .tgz format so you wouldn’t need to unzip it.

I'm not sure I understand this part. Did you want like a dropdown in the UPM ui inside of Unity where people can pick from versions instead of updating the manifest pin manually? If you use the "default" then there isn't really any ping it just checks if there is a newer commit and if there is, it will automatically use it. Notifications for people who are version pinned would probably still go out over email etc. Very sorry again if I am misunderstanding.

In the Package Manager, there is a section for updates where new versions are shown. Unity periodically pings registries and retrieves this information.

As far as I understand, packages installed from a Git URL don’t do this. So when you want to update a Git package, you need to check the latest version available in the repository and then manually update it.

This isn’t very different from our current solution, where you have a list of ZIP files for each version, and you can download the one you need and place it in your project. Ideally, it could be a .tgz format so you wouldn’t need to unzip it.

Got it, you're right:
Git URL packages do not get the same registry-style semantic-version dropdown/history experience.

To recap:
- I am an idiot and didn't realize you started to offer the Google drive access to all old versions, this solves a lot of problems for me going forward and will make it very easy for me to deliver UPM packages internally. Thank you for this.

- Most of the time we handle the UPM package sources and versions etc outside the Unity UPM UI, even if I discover news about a new version via that UI or elsewhere, I usually have to update that fact in another place that maintains the "source of truth", since we treat unity's manifest as something that can "drift" from our desired state and might need to be reconciled. So for professional users, the extra step of creating a scoped registry is nice but not a requirement that meaningfully blocks or improves either way.

- For people who don't do this approach and rely on UPM directly, yes it might be more annoying, but if they use unity and git for UPM, they are probably used to it. And you are right that it would be marginally more convenient than just using your google drive distribution. A scoped registry would provide a nicer experience potentially, but I'm not sure how many people would use or appreciate it vs just a regular boring git style source for the packages.

You still get an update button but it's not a full dropdown like you see on others. I don't remember if it shows up in the update section though. I think maybe the more meaningful distinction would be if you had Noesis split up into multiple packages or something later on, because only with scoped registries can your code can depend on code in other packages, unlike a playing UPM package being delivered via git/git+file

TL;DR:
Having a git source at minimum is really nice and convenient, but if it's a fancier scoped registry or openupm thing, then that's a nice to have sometimes, but not a show stopper for work usually if it's missing.

If we ultimately decide not to use GitHub (because it’s not a significant improvement over a private folder containing all versions), I think that at least moving from '.zip' to '.tgz' could still be an important minor improvement. When installing a '.tgz', Unity copies the package automatically, so users don’t need to think about where to extract our plugin. This has been a source of confusion in the past.

I would also love for Unity to support installing a '.tgz' directly from a remote (`https://`) location, but I’ve been testing it and it seems that it doesn’t work.