Version Dependency Graphs

[yngtdd]

Create new versions that represent breaking changes and feature releases.

Proposed Approach

When a new feature or a breaking change is introduced, we now need a new source tree which does not interfere with previous working versions. The simplest approach would be a single directed graph without branching:

┌──┐      ┌──┐      ┌──┐
│  ├─────►│  ├─────►│  │
└──┘      └──┘      └──┘

For simplicity, we would not allow branching:

1.0        2.0       3.0
┌──┐      ┌──┐      ┌──┐
│  ├─────►│  ├─────►│  │
└──┘      └─┬┘      └──┘
            │
            │       ┌──┐
            └──────►│  │
                    └──┘
                     4.0

This would require that we keep logs for all possible versions, and store the feature and bug set logs for each version for each customer.

Open Questions

1. Would we be able to plan new features across customers?
2. How do you manage these dependency graphs with the ability to create new generic microservices?