3 ms·

In theory, sure. In practice, consumers end up pinned on old/outdated versions of the libraries they depend on, because upgrading is hard, and they often lack a

In theory, sure. In practice, consumers end up pinned on old/outdated versions of the libraries they depend on, because upgrading is hard, and they often lack a specific incentive to stay on top of the most recent version of each library. The "consumers are responsible for library upgrades" approach, also requires every single consumer team to become knowledgeable about changes between library versions, rather than having one specialized team or individual that can stay on top of it and do the work for the whole organization.

mlthoughts2018 8y ago
I agree with both of your paragraphs, except that I see them as being applicable in practice not in theory, and I think both things you mention are positive things. Using pinned / outdated versions to preserve legacy behavior is better than the alternatives for preserving old functionality in a monorepo, where it leads to uncontrollable feature flag growth and an inability to delete code. Likewise, compelling consumer teams to program defensively around all dependencies is a huge positive, not negative.
- slavik81 8y ago
  > Using pinned / outdated versions to preserve legacy behavior is better than the alternatives for preserving old functionality in a monorepo, where it leads to uncontrollable feature flag growth and an inability to delete code. I wonder if it becomes an incentive to delete code. Keeping old projects up to date with every library change is a continuous maintenance burden, incentivizing their removal. The cost of updating exists either way, of course, but the matter of who pays that cost and when it must be paid would probably affect decision making.
  - mlthoughts2018 8y ago
    I agree, but a further point is that not all consumers need to or care about upgrading. I worked on a project before that used an 8 year old version of an in-house dependency. It worked perfectly for us, and out use case did not jam up or limit the team that owned that library. It morphed into something completely different after years of development, and the library team would have been hamstrung if they could not have innovated the ways they did on account of needing every merged commit of the code to continue to support our old legacy use case. You could think of it in terms of Python 3 and Python 2 for example. Imagine if Python was an in-house library at Bank of America. Tons of teams there still happily use Python 2, and plan to keep on using it for a while even after official support is deprecated from libraries, etc. If it lived in a monorepo with this deployment policy (that everything had to be in sync on every merged commit), then you could never attain implementation of Python 3. The same idea plays out at all sorts of scales. It’s not even necessarily part of monorepo tools, it just happens to be a misguided way that a lot of organizations set up their monorepos.
    - NewsAware 8y ago
      Very tue. Coming back to OP, long before this point would have been reached, you might have switched to a different process (probably including VCS setup). But as OP states: many of us are not Bank of America

mlthoughts2018 8y ago

I agree with both of your paragraphs, except that I see them as being applicable in practice not in theory, and I think both things you mention are positive things. Using pinned / outdated versions to preserve legacy behavior is better than the alternatives for preserving old functionality in a monorepo, where it leads to uncontrollable feature flag growth and an inability to delete code. Likewise, compelling consumer teams to program defensively around all dependencies is a huge positive, not negative.

slavik81 8y ago
> Using pinned / outdated versions to preserve legacy behavior is better than the alternatives for preserving old functionality in a monorepo, where it leads to uncontrollable feature flag growth and an inability to delete code. I wonder if it becomes an incentive to delete code. Keeping old projects up to date with every library change is a continuous maintenance burden, incentivizing their removal. The cost of updating exists either way, of course, but the matter of who pays that cost and when it must be paid would probably affect decision making.
- mlthoughts2018 8y ago
  I agree, but a further point is that not all consumers need to or care about upgrading. I worked on a project before that used an 8 year old version of an in-house dependency. It worked perfectly for us, and out use case did not jam up or limit the team that owned that library. It morphed into something completely different after years of development, and the library team would have been hamstrung if they could not have innovated the ways they did on account of needing every merged commit of the code to continue to support our old legacy use case. You could think of it in terms of Python 3 and Python 2 for example. Imagine if Python was an in-house library at Bank of America. Tons of teams there still happily use Python 2, and plan to keep on using it for a while even after official support is deprecated from libraries, etc. If it lived in a monorepo with this deployment policy (that everything had to be in sync on every merged commit), then you could never attain implementation of Python 3. The same idea plays out at all sorts of scales. It’s not even necessarily part of monorepo tools, it just happens to be a misguided way that a lot of organizations set up their monorepos.
  - NewsAware 8y ago
    Very tue. Coming back to OP, long before this point would have been reached, you might have switched to a different process (probably including VCS setup). But as OP states: many of us are not Bank of America