add dotnet-minver

[adamralph]

Closes #94

[bording]

Why make this be something that has to be invoked via dotnet? Global tools don't have to be. This could just be a minver tool.

[adamralph]

@bording I do indeed need some schooling wrt to dotnet tools.

BTW - the tool package was requested by @thefringeninja.

Are you saying that it can be just called minver and dotnet tool install will do whatever magic needs to be done to make it runnable? Will that work on all platforms?

[bording]

@adamralph Yes, you can install a global tool, and then you'll just magically have a minver tool. It will work on all platforms, with the caveats around LibGit2Sharp linux distro issues.

[bording]

The tool name will default to the project name, but you can set the ToolCommandName property in the project file to override that.

Based on that, a rethink of all the project names might be in order. I've been thinking that might generally be a good idea, because things are a bit mixed up right now.

[adamralph]

Yes, you can install a global tool, and then you'll just magically have a minver tool. It will work on all platforms, with the caveats around LibGit2Sharp linux distro issues.

Interesting. What's the general guidance on this? I've seen plenty of NuGet packages named dotnet-xxx, e.g. https://www.nuget.org/packages/dotnet-watch, and they seem to stick to the dotnet-xxx naming for the actual executable too. But I guess they are specifically for the .NET CLI, e.g. "to watch for source file changes during development and restart the dotnet command" whereas minver is useful for any git repo.

Based on that, a rethink of all the project names might be in order. I've been thinking that might generally be a good idea, because things are a bit mixed up right now.

I'm all ears. 👂 😉 I guess if this does become just minver then not only the project names, but the package names will need some thinking about too.

[bording]

Interesting. What's the general guidance on this? I've seen plenty of NuGet packages named dotnet-xxx

A lot of those packages are for the older, project-scoped cli tool references. From what I've seen, the guideance at this point is to only name your tool dotnet-xxx if it actually has some direct reason why the tool would only be useful if the .NET SDK is actually being used.

Since MinVer is more general purpose, having the tool be minver makes a lot of sense to me.

[bording]

I'm all ears. 👂 😉 I guess if this does become just minver then not only the project names, but the package names will need some thinking about too.

Right now, the MinVer.Tasks project is the actual commandline tool invoked by MSBuild, and it has a project reference to MinVer. However, MinVer is the project that has the MSBuild targets, requires the publish output from MinVer.Tasks, and builds the package, so it's actually a bit of a circular dependency. The MSBuild stuff is also split between two projects.

Instead, I think we should turn MinVer into something like MinVer.Core, and it just has the actual versioning logic in it. Then we need an additional project for each of the "shipping vehicles" we want, in this case, something running inside of MSBuild, and the commandline tool being proposed by this PR.

At the moment, the MSBuild project would also have a dependency on the commandline tool, but we should still be able to make that work. In the future, the MSBuild project should probably just become an MSBuild task, and then that dependency is removed.

[adamralph]

👍 thanks @bording, some valid points there. I've raised #103 to continue that conversation. I'll merge this as-is, but I won't publish the tool package until after #103 has been addressed.

[adamralph]

Renamed to minver-cli in #105.

[adamralph]

Released in alpha 15.