Fix deploy error in github actions

[Gandifil]

========================================
DeployToMyGetTask

Pushing MonoGame.Extended.Gui.3.9.0.275.nupkg to 'https://www.myget.org/F/lithiumtoast/api/v2/package'...
PUT https://www.myget.org/F/lithiumtoast/api/v2/package/
Conflict https://www.myget.org/F/lithiumtoast/api/v2/package/ 288ms
To skip already published packages, use the option --skip-duplicate
error: Response status code does not indicate success: 409 (The package could not be uploaded. The package "MonoGame.Extended.Gui 3.9.0.275" does not comply with Semantic Version. Non-SemVer packages are forbidden according to the package retention settings for this feed.).

Usage: dotnet nuget push [arguments] [options]

Arguments:
[root] Specify the path to the package and your API key to push the package to the server.

Options:
-h|--help Show help information
--force-english-output Forces the application to run using an invariant, English-based culture.
-s|--source Package source (URL, UNC/folder path or package source name) to use. Defaults to DefaultPushSource if specified in NuGet.Config.
-ss|--symbol-source Symbol server URL to use.
-t|--timeout Timeout for pushing to a server in seconds. Defaults to 300 seconds (5 minutes).
-k|--api-key The API key for the server.
-sk|--symbol-api-key The API key for the symbol server.
-d|--disable-buffering Disable buffering when pushing to an HTTP(S) server to decrease memory usage.
-n|--no-symbols If a symbols package exists, it will not be pushed to a symbols server.
--no-service-endpoint Does not append "api/v2/package" to the source URL.
--interactive Allow the command to block and require manual action for operations like authentication.
--skip-duplicate If a package and version already exists, skip it and continue with the next package in the push, if any.

An error occurred when executing task 'DeployToMyGetTask'.
Error: .NET CLI: Process returned an error (exit code 1).
Error: Process completed with exit code 255.

[AristurtleDev]

We should open a discussion around this. @lithiumtoast 's MyGet feed is blocking the push due to a strict requirement on [Major].[Minor].[Patch] SemVer, however the builds include a 4th [BuildNumber] value so duplicate packages are not deployed for prerelease builds.

For now I have disabled the MyGet feed push in the build scripts. I don't think we need to have the MyGet feed as a backup source for prereleases. Pushing the NuGets here as a package on GitHub and deploying prereleases to NuGet nightly/weekly should be sufficient enough.

Moving to push prereleases to NuGet also makes it easier for consumers to download the prerelease NuGets instead of having to setup and configure NuGet sources on the local machine or project.

[lithiumtoast]

About SemVer: technically you can any string to the end by using "pre-releases" by having a hypen. For example, 1.2.3-RC or 2022.11.05-commitid.

I would just be cautious of using NuGet for incremental iterations of how to deploy NuGet packages. I advise to not have "accidents" or otherwise situations where we are constantly, consistently, and frequently more than once a day add additional noise to NuGet which is service that is offered for essentially free by Microsoft. Please do not abuse a free service that literally all .NET developers rely on. I would strongly advise using a personal MyGet feed, or an alternative feed, for "experimenting" and "learning" how to use packages where accidents can be undone. The reason is that NuGet does not allow deleting packages from their feeds. Once you upload it to NuGet technically it's archived forever. You can delist the package and prevent it from popping up in searches but anyone technically download it. This is by design. for good reasons. By the way, I could technically completely break people's flow by deleting packages off my MyGet, preventing people from restoring packages with a specific version. And this MyGet on the free-tier has a limit of total package sizes for a feed. I would not recommend people use MyGet for something they would consider "stable" or "unchanging". In some contexts, like general releases (could possible happen multiple times a day but unlikely and not the average), NuGet is the right solution. In other contexts, like nightly builds or open MRs that generate packages through CI/CD, or otherwise packages that are unlikely to be used by the public at large, NuGet (a free service) is the wrong solution.

I think in the context of MGE, if people want nightly builds, they should really do it the open source way and clone down the repo, build it locally, and forgot about using packages all together.

[AristurtleDev]

I would just be cautious of using NuGet for incremental iterations of how to deploy NuGet packages. I advise to not have "accidents" or otherwise situations where we are constantly, consistently, and frequently more than once a day add additional noise to NuGet which is service that is offered for essentially free by Microsoft.

This is the recommended way of doing per Microsoft and NuGet documentation
https://learn.microsoft.com/en-us/nuget/create-packages/prerelease-packages

I wouldn't see this as abusing the free service, but using it as documented. NuGet will also not display any -prerelease package in the Nuget Package Manager in Visual Studio unless a user specifically clicks the option to opt-in to see prerelease pacakges, so there's no polluting the list. NuGet will also not show a prerelease pacakage if the prerelease pacakge is a lower version than the latest stable version.

I would strongly advise using a personal MyGet feed, or an alternative feed, for "experimenting" and "learning" how to use packages where accidents can be undone.

This is the purpose of prerelease packages. They're not stable, they are expected to possibly contain bugs that will need to be fixed. It's the same scenario for any library where users use the bleeding edge deployment vs the latest stable.

Once you upload it to NuGet technically it's archived forever. You can delist the package and prevent it from popping up in searches but anyone technically download it. This is by design. for good reasons.

As mentioned above, it doesn't pollute the list of pacakges. Users will only see prerelease pacakages in the list if they opt-in to see them (in Visual Studio), or of the prerelease is a higher SemVer than the current stable release.

For instance, here is the NuGet page for NewtonSoft.Json. Notice even there it doesn't list any of the pre-release/beta packages

However, if you opt to see them, they are still there

The list remains clean and only shows if a user opt-in to see them specifically.

By the way, I could technically completely break people's flow by deleting packages off my MyGet, preventing people from restoring packages with a specific version.

This is another reason to use NuGet instead of a personal git feed. There's accountability in this way, we can't just delete a package that breaks a users project.

I think in the context of MGE, if people want nightly builds, they should really do it the open source way and clone down the repo, build it locally, and forgot about using packages all together.

This i 100% agree on, but the community at large are not the ones to clone source and reference that. Over the past year or so in the MonoGame discord, there are several questions that come up for MGE where we have to explain that the issue was fixed in develop and to download source and use that instead. Then the user goes and discovers the MyGet feed with the -alpha nugets and uses that instead.

The majority of users, whether we like it or not, are going to prefer to use the NuGet out of convince than clone the source and reference. By using NuGet, we keep accountability of the packages since we can't delete them by design, and we're not abusing a free service if we're using the service as intended.

[AristurtleDev]

Would like to clarify also, i mention nightly/weekly packages, but that is a bit much, I agree. Ideally it would be during certain milestones before release, that way a prerelease can be pushed and we get feedback before releasing a stable

[AristurtleDev]

Resolved in recent reorg. Dropped usage of MyGet feed