3 ms·

This is really overreaching philosophically when it suggests that external software is "freedom" while monorepos aren't. What the author seems to be objecting

This is really overreaching philosophically when it suggests that external software is "freedom" while monorepos aren't. What the author seems to be objecting to is that teams that manage upstream deps make breaking changes and those changes become interrupt-driven work. From the perspective of the upstream devs that makes their lives tractable, because people get off of old versions and they don't have to support it, and security teams do not have to audit old code, and that prioritizes burning down tech debt and not putting it off endlessly. The work that the author is complaining about is work that probably needs to happen one way or another. The monorepo as a forcing function to burn down tech debt seems to actually be working there. It would probably be a 10x bigger nightmare of years of tech debt if they didn't do that. There might be tweaks that could be made to the process so that there were windows every year where breaking changes could be made so as to batch up the breaking changes coming down the pipe -- and require a variance if someone needed to push an emergency breaking change due to an external requirement.

bradleyjg 5y ago
Maintaining backwards compatible isn’t impossible or intractable. It requires thought upfront and then imposes constraints going forward. Two things many programmers don’t like, but are nonetheless generally good things. A company shouldn’t make it impossible to make breaking changes but it shouldn’t make it easy either. Semver is a good tool to build norms around. If your two year old project is either 0.x or 11.x you should probably be a bit embarrassed.
- lamontcg 5y ago
  Sure but that has nothing to do with monorepo-vs-manyrepo. Those are good things to do in any case. And I suspect you're going to find that inside of Google these are 10+ year long projects which were not designed well enough for that (because honestly nobody does that). And the breaking changes are most likely largely all well intentioned. Without at time machine its just work that needs to get done in one way or another. SemVer also has its problems, and is not a panacea, for example: https://hynek.me/articles/semver-will-not-save-you/ https://hynek.me/articles/semver-will-not-save-you/ And I'm positive Google is aware of SemVer.
  - zzo38computer 5y ago
    Yes, semantic version numbers won't solve everything. But, another problem is too many dependencies, which is independent of the version numbers being used. Sometimes dependencies can conflict, although sometimes there is the way to do it without conflicting. I try to avoid too many dependencies in my programs. I still think that semantic version numbers are still helpful (for released versions; unreleased versions can just use the hash), even though it doesn't always help. If you do depend on undocumented behaviours (or behaviours that are documented to be changed in future), you can specify that you require only one specific version, or a range of versions that they have been tested with. They say "version numbers are unique, orderable identifiers of software releases", and I agree, but you can still do that and still use semantic version numbers too.
    - lamontcg 5y ago
      You gotta realize we're discussing Google and you're talking about things which should hopefully be fairly obvious. And while reducing deps makes sense to any developer experienced enough to have been bitten hard by it, Google faces the problem that due to its size there will be lots of highly specialized code dealing with issues that would too trivial for nearly any other businesses to bother extracting out into dependencies. You should always make things as simply as they can be and no simpler. At Google's scale simple things will be necessarily highly complicated and specialized. You're also still talking about issues of concern to you which don't have any bearing at all on monorepo-vs-manyrepo. Fewer deps are clearly better in either model.
- erik_seaberg 5y ago
  You don't have to maintain the old code forever if you implement the old API using the new API. If you find you can't do that, your dependents can't use it either.

bradleyjg 5y ago

Maintaining backwards compatible isn’t impossible or intractable. It requires thought upfront and then imposes constraints going forward. Two things many programmers don’t like, but are nonetheless generally good things. A company shouldn’t make it impossible to make breaking changes but it shouldn’t make it easy either. Semver is a good tool to build norms around. If your two year old project is either 0.x or 11.x you should probably be a bit embarrassed.

lamontcg 5y ago
Sure but that has nothing to do with monorepo-vs-manyrepo. Those are good things to do in any case. And I suspect you're going to find that inside of Google these are 10+ year long projects which were not designed well enough for that (because honestly nobody does that). And the breaking changes are most likely largely all well intentioned. Without at time machine its just work that needs to get done in one way or another. SemVer also has its problems, and is not a panacea, for example: https://hynek.me/articles/semver-will-not-save-you/ https://hynek.me/articles/semver-will-not-save-you/ And I'm positive Google is aware of SemVer.
- zzo38computer 5y ago
  Yes, semantic version numbers won't solve everything. But, another problem is too many dependencies, which is independent of the version numbers being used. Sometimes dependencies can conflict, although sometimes there is the way to do it without conflicting. I try to avoid too many dependencies in my programs. I still think that semantic version numbers are still helpful (for released versions; unreleased versions can just use the hash), even though it doesn't always help. If you do depend on undocumented behaviours (or behaviours that are documented to be changed in future), you can specify that you require only one specific version, or a range of versions that they have been tested with. They say "version numbers are unique, orderable identifiers of software releases", and I agree, but you can still do that and still use semantic version numbers too.
  - lamontcg 5y ago
    You gotta realize we're discussing Google and you're talking about things which should hopefully be fairly obvious. And while reducing deps makes sense to any developer experienced enough to have been bitten hard by it, Google faces the problem that due to its size there will be lots of highly specialized code dealing with issues that would too trivial for nearly any other businesses to bother extracting out into dependencies. You should always make things as simply as they can be and no simpler. At Google's scale simple things will be necessarily highly complicated and specialized. You're also still talking about issues of concern to you which don't have any bearing at all on monorepo-vs-manyrepo. Fewer deps are clearly better in either model.
erik_seaberg 5y ago
You don't have to maintain the old code forever if you implement the old API using the new API. If you find you can't do that, your dependents can't use it either.