GitVersion – selective versioning multiple assemblies of the same project

2
votes

I’m on a .net c# project composed by a solution with several class library projects.

The source control is managed by git using gitflow as branching model. We have decided that we wanted to implement semantic versioning (http://semver.org/) of the project in order to follow a standard way to communicate our releases. For that we are using GitVersionTask (via NuGet) which works pretty well with gitflow.

Every time we tag a release and we perform a build from the master branch the version of all assemblies are updated and a new release is out for delivery. Only one of the assemblies has a public API, all the other are for internal consume. I would like to know if this is the correct way to manage the version of multiple assemblies of the same project I mean, isn’t it wrong to change the version of every assembly when only a couple (or even just one) was changed? To get thinks more complicated there is strong possibility that some of the “internal” assemblies will be used by other projects so I believe it not very wise to increment a major version of an assembly that didn’t suffer a change just because another assembly of the same project is promoting breaking changes. Should each assembly project be managed on its own repository?

Thanks in advance.

2
semantic-versioninggitversion
I would manage internal and external resources on different repos. There is no reason to have internal code released to the public. - Shawn

2 Answers

1
votes

I know this is a bit of an old question, still:

I want to share a workaround that seems to be working:

  1. GitVersion uses $(Build.SourcesDirectory) to see where the sources are located - src

  2. We can change this using logging commands*

  3. Workaround is to set the Build.SourcesDirectory before GitVersion task

  4. Then gitVersion uses the GitVersion.yml from the project folder (Build.SourceDirectory) and voila - works

After that you might want to roll back the change or not - depending on your need. For me it seems it is nice to scope down to the only nuget package from the collection of nuget packages in our nugetPackages monorepo.

see GitVersion issue and comment

*Example Powershell command: standard PowerShell task; set to inline script; Write-Host "##vso[task.setvariable variable=Build_SourcesDirectory;]$(Build.SourcesDirectory)\$(NugetProjectName)"

0
votes

There is certainly nothing in GitVersion that would help with having separate projects within the same repository. The guidance that we would offer here is that you should use different repositories for the different parts of your application. That way they can be versioned/updated at their own cadence.