20 ms·

> any breaking changes should be dealt with in the same change as the version bump Does this mean that some things will never get updated, as the effort requir

by spion 4y ago

> any breaking changes should be dealt with in the same change as the version bump Does this mean that some things will never get updated, as the effort required is impossibly high?

lallysingh 4y ago
No you use automated systems to do the change. https://mobile.twitter.com/obeattie/status/1080496955753750533?lang=en https://mobile.twitter.com/obeattie/status/10804969557537505...
- spankalee 4y ago
  Even so, the cost is often outrageously high. No to mention that if you're the first team to import a third_party library, you own it and other teams can add arbitrary cost to you updating it. You have to be very aggressive with visibility and SLAs to work around this.
  - admax88qqq 4y ago
    You're basically just describing all the pain with pulling in a dependency regardless of monorepo or not. If the third party dependency does not add enough value to justify the cost then don't add it.
    - 8note 4y ago
      With multirepo setups, you don't necessarily need to update the package for all code at all. Instead, some newer package completely replaces an old one, with no relation to the old dependency package, or with a dependency on some future one, and both can run at the same time while turning the old one off
    - spion 4y ago
      In a multi-repo setup you can upgrade gradually though, tackling the services that need the upgrade the most first. Can you do that in a monorepo setup?
      - onion2k 4y ago
        In a multi-repo setup you can upgrade gradually.. This also means services can be left to rot for years because they don't need to be upgraded, while all the infrastructure changes around them, which is a giant pain when you do eventually need to change something. If you have a multi repo architecture you absolutely need both clear ownership of everything and well planned maintenance.
      - ec109685 4y ago
        The total pain is the same though.
yongjik 4y ago
Effort to update something is high because there's a lot of code, not because it's in a monorepo. Updating the same code scattered across multiple repositories takes as much work in the best case. More realistically, some copy of the same code will stay unupdated because the cost to track down every repository in the company is too much.
- 0x6c6f6c 4y ago
  Can definitely feel this pain personally. Need to upgrade tooling across some dozen or so services and we're investigating how to migrate with potentially incompatible upgrades. So just suffer outage while we merge PRs across some 20 repos? The atomic changes of a monorepo are very beneficial in these cases, removing the manual orchestration of GitOps practices segmented across individual services..
- skybrian 4y ago
  When you say it's "as much work" there's an assumption the code is still used. This was years ago, but when I was doing migrations at Google we sometimes had to deal with abandoned or understaffed and barely maintained code. (Sometimes by deleting it, but it can be unclear whether code by some other team is still useful.) If you're not responsible for fixing downstream dependencies then you don't need to spend any time figuring that out.
  - dx034 4y ago
    Sounds great to me because you are forced to delete code that's not in use anymore. Without the monorepo, that code would still be there with old libraries that are potentially insecure. Deleting code that is not being used anymore happens way too rarely in my opinion.
    - rfoo 4y ago
      The downside is if a product no longer have maintainers you are now encouraged to shut it down, even if it still works and it doesn't cost much to run.
ywoski 4y ago
Almost. We had a UI library on Android that was stuck on an alpha version of the library for three or so years after the library had shipped. Upgrading the library broke many tests across the org, and no one wanted to own going in and getting each team to fix it. Eventually, the library had a v2 release, and people started to care about being able to use it. Ultimately, they just forked the current release and appended a v2 to the package name. Not the norm, but it happens. The monorepo works for Google, but I wouldn't recommend it for most organizations; we have a ton of custom tooling and headcount to keep things running smoothly. From the mobile side, it makes it super easy for us to share code across the 50+ apps we have, manage vulnerabilities quicker, and collaborate easily across teams.
- coryrc 4y ago
  > The monorepo works for Google Does it? Or is it stopping Google from supporting products which only make millions in revenue because of the massive burden of continually updating?
  - ywoski 4y ago
    Oh geez, that's an entirely different can of worms that isn't related to the monorepo. Most products at Google are not dropped because the monorepo makes it difficult for them to support - and I'm not sure how it would or how you got to that association. Also, plenty of products that are killed are not in the monorepo. They are usually dropped due to a mix of things, but a big part is just better product management.
    - 8note 4y ago
      Better project management as in, somebody politicked their way into owning a replacement for a currently running thing? The implemented product, as well as the vision for something like inbox or Google music is still way better than Gmail and YouTube music as the end user
    - KptMarchewa 4y ago
      Fixed that: >They are usually dropped due to a mix of things, but a big part is just worse product management. Google is now at the point where their new projects fail (like Stadia) because they killed old products. Killing products has second-order effects.
tho2i3u4o3i434 4y ago
Google's software mostly uses dependencies already in the google monorepo, so these issues don't crop up. The person/team working on library changes have to ensure that nothing breaks, or the downstream users are notified early on. Don't think this would apply to many companies.
- 8note 4y ago
  That sounds like a huge amount of effort unrelated to your current project, both for those being forced to upgrade, and those organizing the upgrade

by spion 4y ago

> any breaking changes should be dealt with in the same change as the version bump Does this mean that some things will never get updated, as the effort required is impossibly high?

lallysingh 4y ago

No you use automated systems to do the change. https://mobile.twitter.com/obeattie/status/1080496955753750533?lang=en https://mobile.twitter.com/obeattie/status/10804969557537505...

spankalee 4y ago
Even so, the cost is often outrageously high. No to mention that if you're the first team to import a third_party library, you own it and other teams can add arbitrary cost to you updating it. You have to be very aggressive with visibility and SLAs to work around this.
- admax88qqq 4y ago
  You're basically just describing all the pain with pulling in a dependency regardless of monorepo or not. If the third party dependency does not add enough value to justify the cost then don't add it.
  - 8note 4y ago
    With multirepo setups, you don't necessarily need to update the package for all code at all. Instead, some newer package completely replaces an old one, with no relation to the old dependency package, or with a dependency on some future one, and both can run at the same time while turning the old one off
  - spion 4y ago
    In a multi-repo setup you can upgrade gradually though, tackling the services that need the upgrade the most first. Can you do that in a monorepo setup?
    - onion2k 4y ago
      In a multi-repo setup you can upgrade gradually.. This also means services can be left to rot for years because they don't need to be upgraded, while all the infrastructure changes around them, which is a giant pain when you do eventually need to change something. If you have a multi repo architecture you absolutely need both clear ownership of everything and well planned maintenance.
    - ec109685 4y ago
      The total pain is the same though.

yongjik 4y ago

Effort to update something is high because there's a lot of code, not because it's in a monorepo. Updating the same code scattered across multiple repositories takes as much work in the best case. More realistically, some copy of the same code will stay unupdated because the cost to track down every repository in the company is too much.

0x6c6f6c 4y ago
Can definitely feel this pain personally. Need to upgrade tooling across some dozen or so services and we're investigating how to migrate with potentially incompatible upgrades. So just suffer outage while we merge PRs across some 20 repos? The atomic changes of a monorepo are very beneficial in these cases, removing the manual orchestration of GitOps practices segmented across individual services..
skybrian 4y ago
When you say it's "as much work" there's an assumption the code is still used. This was years ago, but when I was doing migrations at Google we sometimes had to deal with abandoned or understaffed and barely maintained code. (Sometimes by deleting it, but it can be unclear whether code by some other team is still useful.) If you're not responsible for fixing downstream dependencies then you don't need to spend any time figuring that out.
- dx034 4y ago
  Sounds great to me because you are forced to delete code that's not in use anymore. Without the monorepo, that code would still be there with old libraries that are potentially insecure. Deleting code that is not being used anymore happens way too rarely in my opinion.
  - rfoo 4y ago
    The downside is if a product no longer have maintainers you are now encouraged to shut it down, even if it still works and it doesn't cost much to run.

ywoski 4y ago

Almost. We had a UI library on Android that was stuck on an alpha version of the library for three or so years after the library had shipped. Upgrading the library broke many tests across the org, and no one wanted to own going in and getting each team to fix it. Eventually, the library had a v2 release, and people started to care about being able to use it. Ultimately, they just forked the current release and appended a v2 to the package name. Not the norm, but it happens. The monorepo works for Google, but I wouldn't recommend it for most organizations; we have a ton of custom tooling and headcount to keep things running smoothly. From the mobile side, it makes it super easy for us to share code across the 50+ apps we have, manage vulnerabilities quicker, and collaborate easily across teams.

coryrc 4y ago
> The monorepo works for Google Does it? Or is it stopping Google from supporting products which only make millions in revenue because of the massive burden of continually updating?
- ywoski 4y ago
  Oh geez, that's an entirely different can of worms that isn't related to the monorepo. Most products at Google are not dropped because the monorepo makes it difficult for them to support - and I'm not sure how it would or how you got to that association. Also, plenty of products that are killed are not in the monorepo. They are usually dropped due to a mix of things, but a big part is just better product management.
  - 8note 4y ago
    Better project management as in, somebody politicked their way into owning a replacement for a currently running thing? The implemented product, as well as the vision for something like inbox or Google music is still way better than Gmail and YouTube music as the end user
  - KptMarchewa 4y ago
    Fixed that: >They are usually dropped due to a mix of things, but a big part is just worse product management. Google is now at the point where their new projects fail (like Stadia) because they killed old products. Killing products has second-order effects.

tho2i3u4o3i434 4y ago

Google's software mostly uses dependencies already in the google monorepo, so these issues don't crop up. The person/team working on library changes have to ensure that nothing breaks, or the downstream users are notified early on. Don't think this would apply to many companies.

8note 4y ago
That sounds like a huge amount of effort unrelated to your current project, both for those being forced to upgrade, and those organizing the upgrade