37

I have been educating myself about monorepos as I believe it is a great solution for my team and the current state of our projects. We have multiple web products (Client portal, Internal Portal, API, Core shared code).

Where I am struggling to find the answer that I want to find is versioning.

What is the versioning strategy when all of your projects and products are inside a monorepo?

  • 1 version fits all?
  • Git sub-modules with independent versioning (kind of breaks the point of having a mono repo)
  • Other strategy?

And from a CI perspective, when you commit something in project A, should you launch the whole suite of tests in all of the projects to make sure that nothing broke, even though there was no necessarily a change made to a dependency/share module?

Improve this question
2
  • 2
    You should mention clearly which VCS you use (seems like git) and which build tool you use. Also which kind of release workflow you use. Also 2 questions in 1 is not good for stackoverflow.
    – tkruse
    Commented Dec 5, 2017 at 3:22
  • This might help you as well: stackoverflow.com/a/56558343/2877982
    – Aage
    Commented May 12, 2022 at 13:25

1 Answer 1

Reset to default
6
+50

What is the versioning strategy when all of your projects and products are inside a monorepo?

I would suggest that one version fits all for the following reasons:

  • When releasing your products you can tag the entire branch as release-x.x.x for example. If bugs come up you wouldn't need to check "which version was of XXX was YYY using"
  • It also makes it easier to force that version x.x.x of XXX uses version x.x.x of YYY. In essence, keeping your projects in sync. How you go about this of course depends on what technology your projects are written in.

And from a CI perspective, when you commit something in project A, should you launch the whole suite of tests in all of the projects to make sure that nothing broke, even though there was no necessarily a change made to a dependency/share module?

If the tests don't take particularly long to execute, no harm can come from this. I would definitely recommend this. The more often your tests run the sooner you could uncover time dependent or environment dependent bugs.

If you do not want to run tests all the time for whatever reason, you could query your VCS and write a script which conditionally triggers tests depending on what has changed. This relies heavily on integration between your VCS and your CI server.

Improve this answer
6
  • 16
    This answer makes a deep-seated assumption that all of the projects inside of the monorepo are related to each other. The concern here is driven by questions like does XXX use version x.x.x of YYY? There are very different problems if subsegments of the code in a monorepo are logically unrelated to each other, and have where versioning of one lineage of subprojects should not be connected to the versioning of another lineage.
    – ely
    Commented Sep 27, 2018 at 20:00
  • 10
    For example, imagine that someone put all the source code of PostgreSQL and TensorFlow into the same single repo. Every time PostgreSQL needs a new version, now TensorFlow needs a no-op version as well, where nothing changes but it has to have its version increased to keep one overall version for the whole repo? Auto-generated change notes based on release tags would become a huge PITA. Now suppose you also add all the Keras source code into the same repo, such that it really matter what version of TensorFlow is used by a given version of Keras, but is unrelated to version of Postgres.
    – ely
    Commented Sep 27, 2018 at 20:02
  • 8
    How would be your solution @Ely? The scenario you're talking about is exactly what I am trying to wrap my head around. One single version for different applications within the mono repo don't make sense.
    – PaulT
    Commented May 7, 2019 at 22:17
  • 1
    Hey @PaulT, what did you end up doing to allow different versions for unrelated projects within a monorepo?
    – John
    Commented Sep 4, 2019 at 9:36
  • 3
    I am using Lerna to manage my monorepo, this ups only the version number of projects when something has changed within (or within its dependencies). That's working pretty well for me, although my monorepo is currently still at a small scale.
    – PaulT
    Commented Sep 6, 2019 at 12:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.