What’s bad about this approach? Probably we can continue all development in *master*, and in case if we decide to release another 1.x release, then create branch from ignite-1.8 tag and cherry-pick required fixes there.
Personally, it looks much more flexible to me. We can develop everything directly in master preparing it for 2.0 and avoiding management of several branches. Imagine that we’ve already released 2.0 and the master became 2.0 only after that event. But later on the community decides to release 1.9, 1.10 or other version and we will have to branch from 1.8 rather than from the master. So, it’s not feasible to predict everything but if we’re agreed that the next version will be 2.0 then it’s ok to develop in the master since there is 1.8 branch that can be used for unpredictable situations. — Denis > On Dec 7, 2016, at 2:04 AM, Yakov Zhdanov <[email protected]> wrote: > >> Master must be periodically merged to 2.0. Looks simple enough, no? > > This may not be always possible and may require to re-implement some > features. However, I vote for this approach until it causes problems. Once > we start to spend more time on merging, master should become 2.0 > development branch immediately. > > --Yakov
