Git submodules vs Nuget packages

Question

Our team has experimented with git submodules for some core CRUD functionality shared by most of our products. We have also successfully used Nuget packages (self-hosted now) f

Answer 1

I prefer using submodules over Nuget packages for frequently changing internal libraries. Here's why:

• Merging: If several developers make changes to the same library at the same time, with submodules, these changes can be merged. With Nuget packages, obviously there's no concept of merging.

• Less wait: With submodules, you push, and then pull with whatever repo you need to use the submodule in. Usually a few seconds. With Nuget you must wait for the package to be be published, typically after your CI process completes.

• Versioning clashes: Again, if several developers make concurrent changes, they may increment the Nuget version # to the same one, despite their changes being different. How much of a pain this is to address depends on your CI process.

• Can make changes in "client" repos: Sometimes it's easiest to flesh out the details of library changes while working on client code that will use the library. With submodules, this is possible. Of course, this is no substitude for test coverage.

Answer 2

As with anything, it depends. Have you considered using a separate CI package repository where every commit to the core module produces a CI package?

The biggest challenge imo is package versioning, as NuGet doesn't support SemVer yet to its full extent (e.g. pre-release versions + build number).

EDIT: nuget.org now supports SemVer 2.0 package versions. See this spec: https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29

Use SemVer properly. You usually don't know the released version number upfront, so your CI package version continues from the latest stable release. CI packages as such are to be considered pre-releases.

E.g.: 2.2.0-CI201209140650 (which is a CI build taken on 2012-09-14 at 06:50 for an upcoming 2.2.0 release) <-- note: this release version can still change, but there's always going to be an update path.

If you adopt SemVer v2.0.0, you can even adopt the following example: 2.2.0-CI.2012.09.14.06.50.

Important note: nuget.org (and by extent any other NuGet server/service out there such as MyGet or VSTS) does not support multiple package versions differing only by build metadata!

This has worked for me using these constraints (and some proper TeamCity build configurations). So in short, these are the hassles:

• proper versioning
• reminder to select proper package source (keep your CI pkgs separate from pre-releases and releases, although technically your CI package is versioned as a pre-release)
• upgrading from a CI pkg to a pre-release might be an issue if the pre-release tag is string-sorted higher than "CI" (e.g. "Alpha"). In this case: uninstall-package "CI" followed by install-package "Alpha".

Hope this helps!