3 ms·

The former approach was release + upgrade all projects. Now if one of those fails post-update you have to build a new release and upgrade all projects _again_.

The former approach was release + upgrade all projects. Now if one of those fails post-update you have to build a new release and upgrade all projects _again_. Multiply that by hundreds of services and it can become pretty annoying. By pulling all the reverse dependencies and testing those _before_ releasing & upgrading you reduce the chance that you need another bugfix release. And with hundreds of projects the average quality of tests does not matter that much. Some projects will happily pass, while some may fail. Those that fail will provide valuable insights.

__alexs 5y ago
> The former approach was release + upgrade all projects. Now if one of those fails post-update you have to build a new release and upgrade all projects _again_. Multiply that by hundreds of services and it can become pretty annoying. I think there are actually at least 3 possibilities when you find a new version of a component breaks something that depends on it? 1) Continue using the old version for however long it still meets it's requirements and then do (2). 2) Make the local changes required to be compatible with the new version. 3) There is actually a bug in the new version and you need to fix the dependency. If (3) is happening a lot it suggests that your test suite isn't good enough or you have some design problems that are making it impossible to provide a stable API.
- Mathnerd314 5y ago
  What it sounds like is that they don't have many unit tests for jvmkit. So rather than write extensive unit tests, they're using integration testing with all the dependencies. I guess it makes sense, network stacks are hard to unit test.
- treffer 5y ago
  Yes, and the whole solution allows you to plan / decide on (2) and (3) - both need that awareness. And (1) is common in the open source and cross organization world. But it is less desirable if both the consumers and producers of the library work in the same place. Version spread causes maintenance cost. And at one point it was a common theme that "an upgrade of JVMKit would have avoided this incident".

__alexs 5y ago

> The former approach was release + upgrade all projects. Now if one of those fails post-update you have to build a new release and upgrade all projects _again_. Multiply that by hundreds of services and it can become pretty annoying. I think there are actually at least 3 possibilities when you find a new version of a component breaks something that depends on it? 1) Continue using the old version for however long it still meets it's requirements and then do (2). 2) Make the local changes required to be compatible with the new version. 3) There is actually a bug in the new version and you need to fix the dependency. If (3) is happening a lot it suggests that your test suite isn't good enough or you have some design problems that are making it impossible to provide a stable API.

Mathnerd314 5y ago
What it sounds like is that they don't have many unit tests for jvmkit. So rather than write extensive unit tests, they're using integration testing with all the dependencies. I guess it makes sense, network stacks are hard to unit test.
treffer 5y ago
Yes, and the whole solution allows you to plan / decide on (2) and (3) - both need that awareness. And (1) is common in the open source and cross organization world. But it is less desirable if both the consumers and producers of the library work in the same place. Version spread causes maintenance cost. And at one point it was a common theme that "an upgrade of JVMKit would have avoided this incident".