Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Improvement] Deprecate GitVersion.Commandline nuget package #3375

Closed
arturcic opened this issue Feb 16, 2023 · 5 comments · Fixed by #3376
Closed

[Improvement] Deprecate GitVersion.Commandline nuget package #3375

arturcic opened this issue Feb 16, 2023 · 5 comments · Fixed by #3376
Assignees
Milestone

Comments

@arturcic
Copy link
Member

arturcic commented Feb 16, 2023

Starting with version v6.0 we will deprecate the GitVersion.Commandline nuget package and the reasons are:

  • There are 2 alternatives that can be used:
    • the dotnet global tool GitVersion.Tool if you have the dotnet sdk installed
    • use the zip files depending on the architecture you run on (you can find the zip files as artifacts of every release)
  • The usage on nuget.org is really low and with every version lower.
@arturcic arturcic self-assigned this Feb 16, 2023
arturcic added a commit to arturcic/GitVersion that referenced this issue Feb 16, 2023
arturcic added a commit to arturcic/GitVersion that referenced this issue Feb 16, 2023
@arturcic arturcic added this to the 6.x milestone Feb 16, 2023
arturcic added a commit that referenced this issue Feb 16, 2023
#3375 - stop publishing the GitVersion.Commandline nuget package
@arturcic arturcic modified the milestones: 6.x, 6.0.0-beta.1 Mar 2, 2023
@arturcic
Copy link
Member Author

arturcic commented Mar 2, 2023

🎉 This issue has been resolved in version 6.0.0-beta.1 🎉
The release is available on:

Your GitReleaseManager bot 📦🚀

@hotchkj
Copy link

hotchkj commented Jun 16, 2023

I understand that this is the direction GitVersion is going, but this is a disappointing change. Previously, I could use NuGet to properly download and cache tooling reliably. It meant that any given build is not immediately subject to the whims of Internet package availability unless the package had actually changed.

Now I have to either re-invent that caching myself or build my own NuGet package. The current alternatives all appear to be global tools, which are not suitable for CI environments, which in turn means a complicated dance of installing these onto something like Docker images. Was this really such a saving that the package had to be removed?

@arturcic
Copy link
Member Author

The current alternatives all appear to be global tools, which are not suitable for CI environments

Can you elaborate more on this? As far as I know the global tools install also in the same location as the regular nuget packages.

@hotchkj
Copy link

hotchkj commented Jun 16, 2023

It's possible I'm unaware of some aspect of global tools. With a NuGet package, I can control where the packages go with environment variables, and have multiple versions co-exist and be requested by version by tooling. With a global tool, I'm not sure how to achieve that; when last I tried, dotnet only worked properly when one version of a tool is present, which doesn't scale across hundreds of repos using different editions of toolings.

@arturcic
Copy link
Member Author

Check this one https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools-how-to-use#use-the-tool-as-a-global-tool-installed-in-a-custom-location

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants