In a cascading pattern, the contributor (an individual or team) sends changes to a downstream version which is more stable and tested with other components. Cascading produces a more integrated and stable release version.

The cascading pattern is useful when:

• You have a lot of components to integrate. For example, in the Linux development process, changes move from component maintainers to "lieutenants," who test the integration of subsystems, to a "benevolent dictator" (sometimes Linus Torvalds himself), who assembles a complete kernel release.
• You have strict requirements for testing, security, or compliance. You can address your requirements at the more stable downstream levels. You protect your developers from the hassle of these requirements, so they can run a more productive and continuous process

The picture above shows three levels: 1) the contributor version; 2) a test or integration version, which would typically be used to test work from several contributing people or teams; 3) the stable release version.

You could add a fourth level to integrate more components, to do user acceptance testing, or to perform localization. However, there is a limit to the number of levels that you can use, because the cascading pattern introduces delays into the bug fix process. These delays also make the cascading pattern poorly suited for continuous delivery, although it works if you use CI and CD at the contributor level.

In the diagram below, a bug (bug 1) was found in the production release. We need to make a bug fix for all versions, not just the production version. The contributor updates his version from the production version to reproduce and fix the bug. This is the correct and normal way to unify developers in a cascading process. However, the bug fix must be applied at several levels to make it back to the production version. The process for fixing Bug 2 is more efficient, because it is closer to the developer. However, we now have a situation where at least one contributor is working on an intermediate version, rather than staying connected to the shared stable version.

Because the path for fixes is complicated, cascading workflows are going out of style and being replaced by workflows with shorter fix paths.