@araq > That is what we like to do though, if not for the upcoming 0.19.2 vs 0.20 > split, then later for the v1 vs v2 split, so we might as well figure out how > to do it now.
IIRC the article mentions how to adapt the model to handle that case (eg for python2 vs python3, or in our case nim1 vs nim2): "every new production release is based on the previous one" holds true for each of nim1 and nim2, so we'd adapt the model by having 2 long-lived development branches (1 for nim1, 1 for nim2) instead of just 1. But the same release+patch strategy still applies: each release(or patch) is short-lived and merged back to its long-lived development branch as soon as it's tagged.
