3 ms·

> I might be required to break backward compatibility > ... > I cannot do these necessary things because every change I make is beholden to every regression tes

> I might be required to break backward compatibility > ... > I cannot do these necessary things because every change I make is beholden to every regression test for every consumer Given that backward-incompatible changes are going to be a fact of life, then at some point, somebody will have to deal with them. We can either write one commit which deals with the library and the consumers at the same time; or we can modify the library in isolation and 3 months later the consumer tries to upgrade and is surprised to find out that the API has changed and the author of that change got hit by a bus. It's the same amount of code either way, but I find small incremental atomic changes are easier to manage than large batches of non-atomic changes.

mlthoughts2018 8y ago
You’re missing the point, which is that not all consumers care about the upgrade, and some may be fine living with the existing version for months, years or even forever. Holding up library development to force resolving breaking changes for that consumer is a waste of time that just prevents the library from moving on and providing changes that other consumers really do want or need. Meanwhile, forcing every consumer to also continuously pay the cost of upgrading is also a waste of time, because that consumer team (and not the library team) knows what their timetable and prioritization should be for when and how to spend effort resolving breakages when choosing to upgrade at whatever point they want. I agree that resolving breakages soon is usually smoother and allows adoption of the new version most quickly. It just turns out this isn’t important, and very often consumers are happy to pay a slightly higher friction cost to deal with breakages in an upgrade but to do it on their decided and deliberate timetable, than to be enforced to have changes thrust on them with monorepo-wide implicit upgrades at every point of a successful merge of code from the library. This is why introducing the extra degree of separation to make dependencies into versioned artifacts stored in an artifact repository is so critical. It allows for setting up whatever automated regression tests you want bases on automatically pulling the latest artifacts. You can get all the same information about what consumer breakages there might be, but instead of that acting as a barrier to merging the code (which is a decision that only the library team should be making), it allows consumer teams to file bug reports or backward compatibility requests that can actually be individually prioritized and planned, instead of enforced always all at one single commit / revision despite the effort to do that not really being a priority for the vast majority of consumer teams. In this sense, it is more atomic. Each set of changes addresses a smaller scope of overall state change of the library. Multiple tiny commits, each addressing different specific bugs or backward compatibility requests in isolation, even if involving coordinated commits in different repos, are more atomic because the scope of the state change is smaller and isolated in each step.
- aidenn0 8y ago
  Two points: 1. Consumers that "didn't care" about new versions will end up caring very quickly in the case of bugs in the version that they are using, and now they will have to make fixes to adjust for a lot of breaking changes at once just to get a bugfix (or more likely they will fork the library to get just the fix they want and eventually you end up with 1 consumer because all the other consumers are using forks of old versions). 2. The number of consumers matters. If you have 2 or 3 consumers of the library versus 10s of consumers it makes a big difference for whether or not the extra degree of separation you are talking about make sense. 3 consumers of an internal library might be "a lot" at a small to medium sized company, while 10s of consumers wouldn't be unheard of at a large company.

mlthoughts2018 8y ago

You’re missing the point, which is that not all consumers care about the upgrade, and some may be fine living with the existing version for months, years or even forever. Holding up library development to force resolving breaking changes for that consumer is a waste of time that just prevents the library from moving on and providing changes that other consumers really do want or need. Meanwhile, forcing every consumer to also continuously pay the cost of upgrading is also a waste of time, because that consumer team (and not the library team) knows what their timetable and prioritization should be for when and how to spend effort resolving breakages when choosing to upgrade at whatever point they want. I agree that resolving breakages soon is usually smoother and allows adoption of the new version most quickly. It just turns out this isn’t important, and very often consumers are happy to pay a slightly higher friction cost to deal with breakages in an upgrade but to do it on their decided and deliberate timetable, than to be enforced to have changes thrust on them with monorepo-wide implicit upgrades at every point of a successful merge of code from the library. This is why introducing the extra degree of separation to make dependencies into versioned artifacts stored in an artifact repository is so critical. It allows for setting up whatever automated regression tests you want bases on automatically pulling the latest artifacts. You can get all the same information about what consumer breakages there might be, but instead of that acting as a barrier to merging the code (which is a decision that only the library team should be making), it allows consumer teams to file bug reports or backward compatibility requests that can actually be individually prioritized and planned, instead of enforced always all at one single commit / revision despite the effort to do that not really being a priority for the vast majority of consumer teams. In this sense, it is more atomic. Each set of changes addresses a smaller scope of overall state change of the library. Multiple tiny commits, each addressing different specific bugs or backward compatibility requests in isolation, even if involving coordinated commits in different repos, are more atomic because the scope of the state change is smaller and isolated in each step.

aidenn0 8y ago
Two points: 1. Consumers that "didn't care" about new versions will end up caring very quickly in the case of bugs in the version that they are using, and now they will have to make fixes to adjust for a lot of breaking changes at once just to get a bugfix (or more likely they will fork the library to get just the fix they want and eventually you end up with 1 consumer because all the other consumers are using forks of old versions). 2. The number of consumers matters. If you have 2 or 3 consumers of the library versus 10s of consumers it makes a big difference for whether or not the extra degree of separation you are talking about make sense. 3 consumers of an internal library might be "a lot" at a small to medium sized company, while 10s of consumers wouldn't be unheard of at a large company.