Vladimir, Plans tend to change over time :) It is a good practice to avoid locking ourselves and be flexible enough to tolerate any possible changes.
For me it is clear that everything related to a new storage model (PageMemory and stuff) as well as other breaking changes have to go to 2.0. Everything else goes to the current master. Master must be periodically merged to 2.0. Looks simple enough, no? Sergi 2016-12-07 12:44 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > Sergi, > > The problem is that all current changes target 2.0, because we do not have > 1.9 in plans at the moment. So it is not clear how to distinguish them. > If 1.x is ever will be planned, most likely it will be bug-fix release. IMO > it is better to continue all development in master and branch out of > *ignite-1.8* tag for 1.x release if needed. > > On Wed, Dec 7, 2016 at 12:36 PM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > I think it is good idea to be able to continue releasing 1.X versions. It > > may take quite some time to make Ignite 2.0 stable enough. Thus I'm for > > keeping changes targeted exclusively to 2.0 in a separate branch for now. > > > > Sergi > > > > 2016-12-07 12:23 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > > > > > Igniters, > > > > > > We are moving towards Apache Ignite 2.0. This release will contain lots > > of > > > changes which break compilation on user side and change internal binary > > > protocols. The question is - where to continue development of 2.0 > > features? > > > > > > We can do that in master branch. But what if we decide to release > Apache > > > Ignite 1.9 at some point? In this case we cannot use master branch > > because > > > it will contain incompatible API changes. As alternative we can create > > > separate branch for 2.0 and merge all breaking changes there. But it > will > > > complicate development process. > > > > > > 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. > > > > > > Please share your thoughts. > > > > > > Vladimir. > > > > > > > > > -- > Vladimir Ozerov > Senior Software Architect > GridGain Systems > www.gridgain.com > *+7 (960) 283 98 40* >
