pingvinen
commented
3 years ago A bit of context on where this idea comes from :)
We typically have a repository with 1 solution and multiple projects... e.g.
src/main/main.csprojwhich is the primary thing in this repository (most likely a web service of some sort) - this is the thing we are versioning- various test projects like
src/*-tests/*-tests.csproj- we do not care about the version on these
In this case we do not really need anything to be recursive, except if we want the nice developer experience of being able to bump the version from the root of the repository instead of having to cd down into the main directory.
Sometimes, though we also have an additional project:
src/client/client.csprojwhich contains a typed client for using the service provided bymain- on this thing the version matters and we tend to keep it the same as for the service itself
To handle this case today, we have a conceptually simple powershell script that knows how to bump the version on main and then apply the same version to client - and then doing the git commit and tag.
Adding this usage to an old repository
If we implement this recursive feature and someone wants to start using it on an old repository with billions of projects and version strings that are all over the place, we should perhaps make sure that it is easy to run a command to make all the versions the same. Perhaps something like...
$ cd /root/of/repos
$ dotnet version --recursive --get-highest # getting the highest version number from the csproj files
highest version found: 34.12.666
$ dotnet version --recursive 34.12.666 # setting the given version number on all projects found
nover
Basically
-r|--recursivewhich will then search from current directory and down, finding all csproj files, and update them to the same version.Suggestion to keep it simple at first is that the first csproj file found should serve as the "master" version that is used to update the version in all located csproj files.
Perhaps also limit the recursive depth that it searches.