Components diagram for the v6

[arturcic]

Here is a conceptual components diagram that I think we should split the current code

Those that are in yellow will be packaged as nuget packages.

Details:

• GitVersion.Common - will contain the interfaces needed for version calculation, for build agents and output, git interfaces as well as common infrastructure interfaces like ILogger, IFileSystem and so on.
• GitVersion.Core - will contain the implementation of infrastructure interfaces as well as the version calculation logic and configuration reading, writing, computing the effective configuration.
• GitVersion.BuildAgents - will contain different build agents implementations. The package will be referenced by GitVersion.App and GitVersion.MsBuild
• GitVersion.Output - will contain different output options implementations like file, envvars, a formatted string and so on. The package will be referenced by GitVersion.App and GitVersion.MsBuild
• GitVersion.LibGit2Sharp - will contain a libgit2sharp implementation of the git interfaces. The package will be referenced by GitVersion.App and GitVersion.MsBuild
• GitVersion.ManagedGit - will contain a managed git implementation of the git interfaces. The package will be referenced by GitVersion.App and GitVersion.MsBuild
• GitVersion.App - the dotnet tool that references GitVersion.Core as libs and GitVersion.BuildAgents, GitVersion.Output and (GitVersion.LibGit2Sharp or GitVersion.ManagedGit)
• GitVersion.MsBuild - similar to GitVersion.App

In case someone wants to use the GitVersion as a lib and use the version calculation in their code, they will be able to reference the
GitVersion.Core, either GitVersion.LibGit2Sharp or GitVersion.ManagedGit and optionally GitVersion.BuildAgents and GitVersion.Output. The consumer will be able to provide he's own BuildAgent implementation or output format they need

[HHobeck]

I'm not sure if common is a good naming. Maybe Contract or Abstractions? Everything else looks good for me.

[arturcic]

Naming is hard, you know ;), but I agree,

[arturcic]

My question is what should we do with GitVersion.Configuration - should it be a lib dependency for GitVersion.Core? In that case GitVersion.Configuration will implement the Configuration interfaces defined in GitVersion.Abstractions and then in GitVersion.Core we consume only those Configuration interfaces that will provide the EffectiveConfiguration? Is it EffectiveConfiguraton enough or we still need GitVersionConfiguration as well?

[HHobeck]

Very good question. For me it is fine if we do this like you described it. In my opinion we need the GitVersionConfiguration as well. You can think of the GitVersionConfiguration+BranchConfigration=EffectiveConfiguraton and Branch+EffectiveConfiguraton=EffectiveBranchConfiguraton. If we are iterating to the branches then we have sometimes more then one EffectiveBranchConfigurations to determine the next semantic version. Thus it needs to be present in the Core library.

[HHobeck]

EffectiveBranchConfiguraton is maybe not named correct or even temporary and can be refactored/removed. But at this moment we need the branch information

[arturcic]

GitVersionConfiguration+BranchConfigration=EffectiveConfiguraton and Branch+EffectiveConfiguraton=EffectiveBranchConfiguraton.

Can we include the branch information directly in the EffectiveConfiguraton ?

[HHobeck]

Can we include the branch information directly in the EffectiveConfiguraton ?

Of course we can do this. :)

[arturcic]

Updated

Edit diagram

[arturcic]

@asbjornu can you edit this diagram and provide your visions?

[HHobeck]

Okay never mind. So you mean we are skipping the hole Abstractions.dll or Common.dll idea and put everything in one Core.dll? As a consequence I want to point out that all other projects have in this design a reference to the Core.dll. Is this assumption correct?

[HHobeck]

It might be possible as long we have no circular references.

[asbjornu]

Yes, I prefer Core as it explains the project's purpose in the architecture much more explicitly and precisely than Common. Core should not reference anything whatsoever other than mscorlib.dll. All other projects in the solution should reference Core, but not the other way around.

[asbjornu]

@asbjornu can you edit this diagram and provide your visions?

Yes, will do.

[arturcic]

Well the current state of the code base: we have Core that has basically every interfaces, then we have the Output, LibGit2Sharp and BuildAgents modules that depend on Core where their interfaces are defined, and implement in each specific module.

Then we have the consumer apps or the packages/tools that the GitVersion user will actually use - GitVersion.Tool and MsBuild.

These 2 apps will reference the Core and the modules.

The idea behind the Abstraction was to move the interfaces to the new module out of Core so the the Output, LibGit2Sharp and BuildAgents do not rely on the Core for the interfaces. The problem I see in the current state is the Core beside the interfaces for the modules (aka contracts) also contain the version calculation logic. So we need to make a design that does not couple the modules to the Core (that is kind of Contracts + Version calculation). @HHobeck @asbjornu let me know what are your thoughts on this?

[asbjornu]

Okay, I've finally found some time to take a look at this. I don't think we need to adjust the proposed diagram much.

I suggest we do is merge Common into Core. Core should not have any external dependencies and I don't think we need another common project in addition to Core.

I'm also a bit unsure about whether we want to publish all of the projects marked with nuget as NuGet packages. Isn't the dotnet tool, standalone CLI and MSBuild Task enough?

Lastly, GitVersion.Configuration seems to be missing from your explanation. I've included it in the table below.

Project	Description
GitVersion.Core	Contains the interfaces needed for version calculation, for build agents and output, git interfaces as well as common infrastructure interfaces like ILogger, IFileSystem and so on. Also contains all objects and business logic for version calculation.
GitVersion.Configuration	Contains the implementation of the configuration interfaces, with external dependency on YamlDotNet.
GitVersion.BuildAgents	Contains different build agents implementations. The package will be referenced by GitVersion.App and GitVersion.MsBuild.
GitVersion.Output	Contains different output options implementations like file, envvars, a formatted string and so on. Will have a dependency on Newtonsoft.Json (probably). Will be referenced by GitVersion.App and GitVersion.MsBuild.
GitVersion.LibGit2Sharp	Contains a reference to LibGit2Sharp, implementing the Git interfaces. The package will be referenced by GitVersion.App and GitVersion.MsBuild.
GitVersion.ManagedGit	Contains a managed implementation of the Git interfaces. Might be merged into Core since it shouldn't require any external dependencies. The package will be referenced by GitVersion.App and GitVersion.MsBuild.
GitVersion.App	The dotnet tool that references GitVersion.Core as libs and GitVersion.BuildAgents, GitVersion.Output and (GitVersion.LibGit2Sharp or GitVersion.ManagedGit).
GitVersion.MsBuild	similar to GitVersion.App.