/cc @araq| ---|--- correct; it's simpler than traditional gitflow because in gitflow we must know in advance where a bugfix PR goes (is it v1? is it v2? is it 0.18.x branch? is it 0.17.x release? ) which is often not practical (especially when PR contains multiple commits, only one of which has the bugfix)
with oneflow, you worry about it later when you realize "would be nice to backport this bugfix all the way back to 0.17.x release. * what happens if cherry-picking a bugfix in a commit xyz causes a regression in a release (eg 0.19.2 release) ? well that's the point of creating a (short-lived) branch per release/hotfix before applying a new tag (eg 0.19.3): we apply a number of cherry-picked bugfixes to release/0.19.3 branch (maybe with additional manual commits to adjust if needed) until we're satisfied with CI, and then we finally tag 0.19.3 and merge release/0.19.3 : end of life for that branch.
