Folks, IMHO the most important argument in favor of separate branch for 2.0 I heard is that if we start breaking API in master right now, users will not be able to easily build binaries from master and plug them into their app. Makes perfect sense to me.
I created the branch *ignite-2.0 *from master. I propose to merge all breaking changes to *ignite-2.0*, and the rest to *master*. Master should be merged to ignite-2.0 on regular basis. Please let me know if you have any concerns on this approach. Vladimir. On Thu, Dec 8, 2016 at 11:06 AM, Pavel Tupitsyn <[email protected]> wrote: > 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 > > > > > -- Vladimir Ozerov Senior Software Architect GridGain Systems www.gridgain.com *+7 (960) 283 98 40*
