3 ms·

Semi-related: when people talk about monorepos, is it implied that all the project has only one version number? Why not just version subprojects of the monorepo

by lalos 6y ago

Semi-related: when people talk about monorepos, is it implied that all the project has only one version number? Why not just version subprojects of the monorepo, that way you have a small vetting process when cutting a release of a specific subproject. The rest of the subprojects that depend on it can read the release notes for breaking changes, etc.

reidrac 6y ago
Good question! I always assume it is the same version, mostly because a common pattern is to use SCM tags to track versions, and I haven't seen that work fine on any monorepo. If you have a specific version per subproject, how do you track that in the repo? Different tag schemes for different subprojects? I have used that in a small-ish monorepo and I didn't like it specially.
- derekperkins 6y ago
  We just use the git sha and they works great, no reason to overcomplicate it
mumblemumble 6y ago
When I'm doing it, I version subprojects independently using Git tags, but that's primarily because we mix and match versions in production, which creates need to make version numbering semantic. If we were doing continuous delivery, too, I could see there not being much value in messing with independent versioning, semver, whatever. Just make today's date the universal version numbering system for all modules and move along.
tudelo 6y ago
No. Not at all. A monorepo with multiple back end projects might push all at different times. So what this means is that when designing new features across multiple services you need to design them with push safety in mind with a roll out plan to accomplish that. For example, you are updating service B to call new endpoint on service A. First you need to make service A endpoint available, and then make service B call service A. Just because everything exists in the same repo does not mean it all gets shoved out at once. The downside is that you can't just read the code and assume the running service is doing that, unless it's embedded in your build. Processes like automated updates and a forced update cadence (no running binaries over X days old) with proper canary/vetting before a full release allow a large org to still manage this complexity.
deleted 6y ago
[deleted]
dec0dedab0de 6y ago
To me the whole point of having a monorepo is to avoid versioning. But that doesnt mean you always need to deploy everything, you can take the newest commit hash from each project directory and only deploy if that has changed.

by lalos 6y ago

reidrac 6y ago

Good question! I always assume it is the same version, mostly because a common pattern is to use SCM tags to track versions, and I haven't seen that work fine on any monorepo. If you have a specific version per subproject, how do you track that in the repo? Different tag schemes for different subprojects? I have used that in a small-ish monorepo and I didn't like it specially.

derekperkins 6y ago
We just use the git sha and they works great, no reason to overcomplicate it

mumblemumble 6y ago

When I'm doing it, I version subprojects independently using Git tags, but that's primarily because we mix and match versions in production, which creates need to make version numbering semantic. If we were doing continuous delivery, too, I could see there not being much value in messing with independent versioning, semver, whatever. Just make today's date the universal version numbering system for all modules and move along.

tudelo 6y ago

No. Not at all. A monorepo with multiple back end projects might push all at different times. So what this means is that when designing new features across multiple services you need to design them with push safety in mind with a roll out plan to accomplish that. For example, you are updating service B to call new endpoint on service A. First you need to make service A endpoint available, and then make service B call service A. Just because everything exists in the same repo does not mean it all gets shoved out at once. The downside is that you can't just read the code and assume the running service is doing that, unless it's embedded in your build. Processes like automated updates and a forced update cadence (no running binaries over X days old) with proper canary/vetting before a full release allow a large org to still manage this complexity.

deleted 6y ago

[deleted]

dec0dedab0de 6y ago

To me the whole point of having a monorepo is to avoid versioning. But that doesnt mean you always need to deploy everything, you can take the newest commit hash from each project directory and only deploy if that has changed.