Rename projects and packages

[adamralph]

Rename projects and packages

[adamralph]

Another option for the tool name is something like minver-cli, which would play nicer with dotnet tool list -g:

Package Id           Version      Commands
-------------------------------------------------
dotnet-outdated      2.0.0        dotnet-outdated
dotnet-script        0.25.0       dotnet-script
git-status-cli       1.0.0        git-status

Again, my OCD is averse to adding a PascalCased.WithDots package ID to that list.

[adamralph]

After more thought, I'm homing in on these names as my favourites (for both project and package):

• MinVer: The canonical package. Just install into a project and build.
• minver-cli: The tool package, with command name minver.
• MinVer.Lib: The class lib used by both the above packages. I don't think there's any point in publishing a package until a use case arises. For now, that allows us to break the interface freely.

@bording does that make things clearer?

[adamralph]

One thing I'm not keen on is MinVer.Core. I think I'd be less averse to MinVer.Lib. I've never liked the "core" naming strategy. One option is to keep the class lib named MinVer, but it may desirable to publish that as it's own package at some point, and the current build package is occupying that package name. Still, the package hasn't gone past alpha yet, so that package name could be repurposed for this instead.

Regarding the tool package, it's tempting to call it minver, but again, that slot (case-insensitive) is already taken up the current build package. But since the command name can be controlled independently, it can be called something else. Still, it's a shame not to be able to write dotnet tool install -g minver and then then minver. The problem is, the package is currently pascal cased, MinVer, and I don't think that can be changed now. dotnet tool install MinVer, dotnet minver, isn't much nicer than dotnet tool install MinVer.XXX, minver.

So here are some options:

Project	Package	Description
MinVer/MinVer.Build/MinVer.MSBuild/MinVer.Targets/MinVer.Task	(same as project)	For use in .NET SDK projects (canonical usage). MinVer would require a rename of the class lib.
MinVer.Cli/MinVer.Tool/MinVer.CommandLine/dotnet-minver	(same as project)	For ad-hoc use in any Git repo. The command name in all cases would be minver.
MinVer/MinVer.Lib/MinVer.Core	(same as project)/(none)	For programmatic use on a netstandard2.0+ platform (not entirely sure if we need this yet)
(none)	MinVer/(none)	A meta-package representing the canonical usage. Just takes a dep on the build package (or just de-list this package and stop publishing it)

[adamralph]

For reference: https://github.com/natemcmaster/dotnet-tools

[bording]

@adamralph I'm having some trouble understanding the options you've presented.

[thefringeninja]

What about following the same convention here: https://github.com/RetireNet/dotnet-retire

dotnet tool install -g dotnet-minver
dotnet minver

[adamralph]

@thefringeninja I think I prefer the command name to be just minver. Commands like dotnet watch and dotnet retire are specifically designed for use with .NET SDK projects so it makes sense that you invoke them as a sub-command of dotnet. The MinVer CLI is useful for any git repo, and I think it makes more sense when you're in a nodejs, ruby, or go repo to be typing just minver rather than dotnet minver.

[bording]

@adamralph That does make things much clearer, thanks! I like those names for the projects as well.

With that project structure, I assume the actual commandline code would be in the minver-cli project, and then the MinVer project would have something that gets a copy of minver-cli output to bundle into its package?

Then, in the future, MinVer could change to being an MSBuild task, removing the need to bundle minver-cli, and everything is still layered properly.

[adamralph]

@bording it's slightly different to that. For now, MinVer will remain as a CLI project, since it needs to do MSBuild-specific logging in its Main method. Effectively, it is emulating an MSBuild task, and the values it accepts for the verbosity option reflect that. minver-cli will have no MSBuild knowledge. When MinVer changes to an MSBuild task, that will be a purely internal change in that project to switch from invoking the CLI via the Exec task to using the MinVer task (or whatever it's called).