I agree with Denis. Next planned release is 2.0, so let's work in master. No extra branches, no confusion. Working in a separate branch is an inconvenience that will turn out unnecessary if there is no 1.9.
On Thu, Dec 8, 2016 at 12:55 AM, Denis Magda <[email protected]> wrote: > 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 > >
