[qznc]

It believe it is a question of maturity. If the subcomponent is mature enough, then turning it into a package is fine. The cost is that patching the subcomponent and testing the main component takes more effort (though you can script it). With submodules at least the build and test cycle is as quick as if it is in the same repo.

So there is a scale from quicker iteration to less coupled: same repo, submodule, different package. The question is in which cases the middle step "submodule" is worth it or if you should rather switch to one of the others always.

[weitzj]

Exactly what I am thinking. My use case is to have a shared api repository containing an IDL (here protobuf/grpc) and you hook it up as submodules for iOS, android, Golang. The round trip time is reduced compared to creating and publishing modules for each generated code. This makes it far easier to experiment with a new api feature so one gets a better feeling how this behaves in each language. And if the api is mature enough you might as well change your development flow into publishing modules instead of using git submodules.

Therefore I like submodules and would argue that people might underestimate the increased round trip time for publishing modules and then referencing them in code compared to using submodules