Not sure if this is a great place for feedback in regards to this change but this is a real bummer move.

Packages being served from the Unity Package manager makes asset installation / management much less painful then a third party asset install. I would love to know the logic behind this shift.

Just as an aside, not trying to sound rude here, I'm genuinely curious why this shift is happening.

Last month, we spent the better part of a week migrating our Firebase projects to the UPM registry instead of UnityPackages. It would be nice to know why this is changing. UPM is the future of Unity integrations!

I don't see the benefit in this change. I too would love to get some more official communication on this.

Agreeing with the previous comments: moving away from UPM in favor of the quite outdated and inconvenient method of importing each package is five steps backward instead of one forward...

This seems like a massive backwards step. Is there any reason it's required?

Googl WTF u doin

Please keep the UPM integration! I don't want to go back to manually importing .unitypackage files. The manifest makes it really easy to see which Google Products are installed and more importantly what version they currently have.

What was the reason for this change? can we know?

I really don't understand why this change is being done. Unity Package Manager made the plugins integration/update WAY easier than manual import of Unity Packages.

Agree with everyone else on this thread. The UPM integration is really useful, and there should be more of it, not less.

Same question: WHY? 🙄

What should be deprecated is unitypackage not UPM

Why? UPM seems like the future of package integration not the other way around... ?

This is very sad news and a step back. It would be interesting to know why this decision happened.

For now, I guess for simpler upgrading, we will just create our own UPM packages from .unitypackage files supplied by Firebase

Can Firebase explain the reason why the do this?

now that UPM isnt supported Whats the right way to deal with this github issue? remote: error: File Assets/Firebase/Plugins/x86_64/FirebaseCppApp-7_1_0.so is 105.01 MB; this exceeds GitHub's file size limit of 100.00 MB

It is indeed very sad news. The Google Firebase UPM-packages was a great example of how a major 3rd-party developer like Google can properly serve their Unity SDKs. I believe that one day you'll need to shift back because Unity Package Manager is the future for 3rd-party Unity SDK developers.

Google moving to UPM was one of the best things that happened regarding Unity Firebase integration. We provide packages internally via UPM as well and it is a super smooth ride for product teams to install, upgrade etc their packages, the same goes for Firebase packages.
I'm sure there's a very good reason for this change, but it really feels like a massive downgrade process and experience-wise for developers using Unity.

Very bad decision.

Please by all means reconsider this horrible decision made by someone who obviously knows nothing about managing dependencies in projects

Honestly, from our perspective this is a huge step backwards. I'd really be quite interested in knowing the rationale behind this, and the rationale for the relatively short amount of time to make the required changes to our processes and teams.

It's time write feature requests to get UPM packages back https://firebase.google.com/support/troubleshooter/report/features

Google moving to UPM was a big improvement regarding Unity Firebase integration.
We provide packages internally via UPM as well and it is a super smooth ride for product teams to install, upgrade etc their packages, the same goes for Firebase packages (and all UPM packages).
This change feels like a massive downgrade in process and workflow for developers using Unity,
and I would like to know the reason for this change as in my mind, it has to be a really good one to justify this 'backwards' change.

Google moving to UPM was a big improvement regarding Unity Firebase integration.

We provide packages internally via UPM as well and it is a super smooth ride for product teams to install, upgrade etc their packages, the same goes for Firebase packages (and all UPM packages).

This change feels like a massive downgrade in process and workflow for developers using Unity,

and I would like to know the reason for this change as in my mind, it has to be a really good one to justify this 'backwards' change.

@EgillAntonsson-MagInteractive I surely doubt there is any good reason to justify this. To make such a big change with only a month notice surely stinks and no sane developer would do this, at least not in such a short time.
This feels like a really bad management decision made by someone who has never used Unity at all.

1 sad about this news and worried about keeping the compatibility in the near future.

**I sent Firebase feature request and got an answer.

"I appreciate the feedback. We're still discussing it with our gurus. I'll get back to you once I have more information to share."

**

According to this they at least seem to be listening.
Hopefully they will not go through with this.
At least if they for some reason really need to close down GPR at least have the .tgz files online on a location where we could directly reference them in manifest.json

Lets hope the best. To show them your concern you should send them Feature request as mentioned above to let them know of our worries.

Thanks for the feedback. It matters a lot to us.

Our previous solution is no longer compatible with Unity's vision for scoped registries as reflected in their new package guidelines, so we've decided to switch to Google APIs for Unity.

We still provide .tgz files for developers and will continue to invest in this format.

We'll continue to seek new ways to improve the experience, and this feedback helps us understand what's working and what's not.

Reading Unity's package guidelines:

B. You cannot make any Package (including via Package update) available from within the Unity Editor to third parties (other than your Designated Users) if such Package provides a service that collects or aggregates data. For example:

A Package that enables a third party analytics service.

Yeah... guess that answers the "why".

Thanks for the feedback. It matters a lot to us.

Our previous solution is no longer compatible with Unity's vision for scoped registries as reflected in their new package guidelines, so we've decided to switch to Google APIs for Unity.

We still provide .tgz files for developers and will continue to invest in this format.

We'll continue to seek new ways to improve the experience, and this feedback helps us understand what's working and what's not.

Thanks @chkuang-g for quickly replying to us.

Personally I didn't knew of this change in Unity terms. Have you contacted Unity and asked whether that applies to you at Google ?

One question as you mention that you will continue to support the .tgz files which I guess are the base behind the packages on your GPR.
It seems however that direct reference to .tgz over https is not supported in Unity. However Git is.

My question to you @chkuang-g is therefore

Could you make a Git repository for the released packages where you create a tag for the released versions ?

I did myself sometime ago create Git repository for Branch.io releases for Unity to avoid using .unitypackage
It's included as such in manifest.json
"com.mussila.branch-sdk": "https://github.com/snorrsi/branch-upm.git?path=/upm#v0.6.6",

EDM4U could manage the manifest.json for users in the longer run but at least including the packages through Git would not break the current behaviour as we could easily swap out the version number to Github url you specify.
(Guess we could create package hosting for ourselves but it would be much more appreciated if you could host the packages on Github rather than every developer to create their own repository)

Thanks for the feedback. It matters a lot to us.

Our previous solution is no longer compatible with Unity's vision for scoped registries as reflected in their new package guidelines, so we've decided to switch to Google APIs for Unity.

We still provide .tgz files for developers and will continue to invest in this format.

We'll continue to seek new ways to improve the experience, and this feedback helps us understand what's working and what's not.

I still don't understand what you really concern about with the guideline

From what I can see, The only problem is EDM4U that can automatically add scope registry, not because firebase or the scope registry itself isn't it?

They also mention that all those terms is not apply to package that use direct git dependency, I see this as they declaring git dependencies are on equal footing with .tgz. I bet this also actually barring scope registry too if that scope registry was added manually, but even if it's not, you can still provide firebase with UPM by git dependencies directly

So actually this is not the case. Please withhold the idea of tgz and use git dependencies instead

Reference: #1030 (comment)

To import using *.unitypackage is more harder than using UPM.
For example, *.unitypackage can't delete files so is hard to use when I want to update library.
In addition, we can't push the library to github because *.so size is over 100MB.
The UPM integration should be kept.

Yes, please find a way to keep the scoped registry if possible!! This saves so much time and allows us to see updates from within Unity without having to go out and check the archive for each and every package that we use. This would be such a pain. .tgz format is better than unitypackage format, but it still requires manually checking for updates and manually downloading and copying packages. It's all slow and error prone. Thank you @chkuang-g for your explanation.

@chkuang-g At least provide us a public git repository hosted by google on https://cloud.google.com/source-repositories, with on up to date SDK as this Unity license doesn't apply for git packages. This will help us to continue using firebase in the long term.
Example of distribution: https://github.com/GameWorkstore/patterns

I added this to the.gitignore

# ignore big files from firebase
FirebaseCppApp-*.so*

And added this Editor script to give a warning when the big 100 mb file doesn't exist (even though we dont need the file. just so that we will know its missing and can import it if we want)

If you have any improvements please share!

[PostProcessBuild]
public static void checkIfGithubIgnoredBigFilesExist()
 {
     string[] filesToCheck = new string[]
     {
         //"Assets/Firebase/Plugins/x86_64/FirebaseCppApp-7_1_0.so"
         "Firebase/Plugins/x86_64/FirebaseCppApp-*.so",
         //"Assets/Firebase/Plugins/x86_64/FirebaseCppApp-*.so.meta",
     };
     foreach (var searchPattern in filesToCheck)
     {
         // Application.dataPath is <path to project folder>/Assets in editor
         string[] files = System.IO.Directory.GetFiles(Application.dataPath, searchPattern, System.IO.SearchOption.TopDirectoryOnly);
         if (files.Length > 0)
         {
             //file exist
             //foreach (var item in files)
             //{
             //    Debug.LogErrorFormat("Large files found {0}", item);
             //}
         }
         else
         {
             Debug.LogErrorFormat("Large file ignored by github doesnt exist {0} []", searchPattern);
             Debug.Log("[] If FirebaseCppApp-7_1_0.so is missing eveerything should still work because its used on linux. we ignore file on github because it's to big to push. you can download it by reimporting firebase package");

         }

     }
 }

We absolutely can't go back to unity packages. UPM is the future and makes life so easy for managing Firebase.
I hope they find a way to co-exist with Unity's new terms because it feels like we are going back to the dark ages without UPM.

@mgrogin and @npicouet you can use the .tgz files. The files are less than 100 MB (FirebaseApp 72 MB) and you don't need to extract them.

Although it's obviously not as handy as using the scoped registries but they explain the usage of it using relative paths on https://developers.google.com/unity/instructions

@chkuang-g are you really not going to publish this uncompressed tgz packages in uncompressed git repository ?

Although we can go the tgz way that means repository sizes of peoples project on Github will increase and much more data stored than needed. It would be better for the environment if you could host the tgz packages on your Git repository.

Can you at least explain why you are not putting the .tgz files directly uncompressed on Github repository ?

Thank you for the feedback.

Game Package Registry by Google was shut down as planned this week. Google APIs for Unity is the solution we will continue to invest in.

We continue to support the tgz format on the Google APIs for Unity archive page. URLs for accessing these files haven’t changed, and we have no plans to change them.

We are committed to improving workflows for Unity developers, and we’re very open to feedback. If you have suggestions, please make a feature request or upvote an existing one.

@chkuang-g Is it possible that this change causes the Unity editor to crash when still using Firebase 7.2.0 through the Package Manager?
Our project worked without an issue yesterday, but now the editor crashes as soon as we try to use a Firebase call.
Trying the exact same code on an Android device works without any issues.

@Nyankoo I definitely did not experience this issue or expected this.

As we tested before, Unity should keep the local copy even if it is removed from the registry. But Unity can behave differently in different versions.

I would recommend you to walk through the instructions to migrate your packages away from the registry.

Creating #1052 for feature request

There is official comment from unity that using git url in UPM are not related to their new terms. It should be considered that using git url with UPM are no difference from using tgz

https://forum.unity.com/threads/updates-to-our-terms-of-service-and-new-package-guidelines.999940/#post-7158721

@chkuang-g This sadly didn't work, please see #1053

There are currently 2 temporary fast work around to install newer Firebase version 7.2.0 without import .UnityPackage:

1. Install manually through .tgz tarball file. Download from Firebase archive, store it in Package folder and import through UPM.
2. Install through git-url from @john-rosa-playkids whom host it on github (Source)

    "com.gameworkstore.facebooksdkunity": "git://github.com/GameWorkstore/facebook-sdk-unity#9.2.0",

    "com.google.external-dependency-manager": "git://github.com/GameWorkstore/com.google.external-dependency-manager#1.2.165",
    "com.google.firebase.analytics": "git://github.com/GameWorkstore/com.google.firebase.analytics/#7.2.0",
    "com.google.firebase.app": "git://github.com/GameWorkstore/com.google.firebase.app/#7.2.0",
    "com.google.firebase.crashlytics": "git://github.com/GameWorkstore/com.google.firebase.crashlytics/#7.2.0",
    "com.google.firebase.installations": "git://github.com/GameWorkstore/com.google.firebase.installations/#7.2.0",
    "com.google.firebase.instance-id": "git://github.com/GameWorkstore/com.google.firebase.instance-id/#7.2.0",
    "com.google.firebase.remote-config": "git://github.com/GameWorkstore/com.google.firebase.remote-config/#7.2.0",
    "com.google.play.review": "git://github.com/GameWorkstore/com.google.play.review/#1.4.0",
    "com.google.play.common": "git://github.com/GameWorkstore/com.google.play.common/#1.4.0",
    "com.google.play.core": "git://github.com/GameWorkstore/com.google.play.core/#1.4.0",
    "com.google.android.appbundle": "git://github.com/GameWorkstore/com.google.android.appbundle/#1.4.0",