Versioning a monorepo

[sreejith-ms]

Any thoughts on supporting a monorepo?

Currently, versionize shows an error message if multiple project files have different versions.

[nerdybynature]

How would that work? How would you differentiate which commit is for which project to be able to set the correct semantic version for each project?

[saintedlama]

I think that a joint versioning strategy could be implemented in which each project will have the same version number. A disjoint versioning schema will be more complex taking project dependencies into account

[sreejith-ms]

@saintedlama @nerdybynature Take a look at my fork (a quick and dirty one:blush:, but did the purpose for me).

Here is the gist:

Create a version.json file for each projects in solution (similar to GitVersioning)

Here is a sample version.json file

{
  "version": "1.0.0",
  "scopeName": "foolib",
  "parentScopes": []
}

• version indicates the current version of the project.
• scopeName is used to indicate the package names in a monorepo
• The scopeName must be used in the commit message, it is the [optional scope] in conventional commits specification.
• Sample commit message: feat(foolib): add foobar
• The versioning of the package is calculated by using the scopeName. The scopeName also used in tagging and changelog.
• parentScopes is used to indicate a dependency packages. Suppose a project foo depends on another project bar, then a commit in bar should cause a version bump in foo. To acheive this the parentScopes in foo must refer to bar. Example: "parentScopes": ["bar"]
• The version gets bumped based on your commit history with scope

[clarity99]

I'd be happy if all the projects had same version number...

[gsroberts]

I'll toss my vote in for this one as well.

I have a project that has a structure like:

repo
- api (console)
- authentication (library)
- configuration (library)
- data (library)
- logic (library)
- security (library)
- utility (library)

All projects belong to the same application (call it "api").

I currently use the /p:AssemblyVersion and /p:Version parameters of the dotnet publish command to increment the version number of the generated assemblies manually during my CI build based on the most recent tag found on the repo.

Only one project (api) has a <Version> tag in its .csproj file.

Ideally, I'd be able to add versionize into the mix to automatically increment the version number based on conventional commit messages prior to execution of dotnet build. That way, the CI and the assemblies would all have the same version.

[cabauman]

Someone contributed #121 recently, so I'll go ahead and close this issue. If it doesn't match your expectations, feel free to create a new issue.