3 ms·
If you always pull the latest version of other projects, you have no way to have a consistent snapshot of a working system. If you use a monorepo, it means that
by michaelmior 11y ago
If you always pull the latest version of other projects, you have no way to have a consistent snapshot of a working system. If you use a monorepo, it means that you always know which versions of every file in every project are in use at a particular commit. This of course is also true if you use separate projects and pin their dependencies. But if you use separate projects and always grab the latest version of each subproject, there's no way to ensure you have compatible versions of different projects in use.
- hvidgaard 11y agoAt least in TeamCity, I can tell it what version of an artifact I want, it's even possible from within the VCS with some powershell magic. So a non breaking change like a bugfix, will update the buildnumber, but not the rest. If the fix includes breaking changes, I want to adapt my code anyway, and then update the reference to the newest version anyway. For our .net projects, I've set up an internal NuGet repo to handle internal dependencies. This honestly sounds more like the best workaround because the tooling isn't good.
- theCodeStig 11y agoYou don't need a monorepo to solve this problem. The dependent projects would depend on a specific version of an artifact, rather than a 'latest' pointer. Example: Project 1 depends on version 1.2.3 of Library A, and Library A builds are hosted in an artifact repo. Project 2 needs an update to Library A, and those updates are built and released as version 1.3.0. Project 1 continues to use version 1.2.3, until it's updated to work with the new 1.3.0 API.
- michaelmior 11y agoOf course you don't need a monorepo to solve the dependency problem. My point was that just using the latest version of all projects in different repos is not necessarily an acceptable solution.