3 ms·

Maintaining backwards compatible isn’t impossible or intractable. It requires thought upfront and then imposes constraints going forward. Two things many progra

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.

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.