Hello, Alexey. I think that «rewriting from scratch» approach has a high risk to make new features unusable. At the time Ignite2 was started no-one wants to do bad UX or bad features. Nevertheless, it happen.
I think we can avoid it with the Ignite3 and successors if we will move step by step without keeping backward compatibility With the step by step approach, we can focus on each component separately. > What new features are we planning to implement for Ignite 2.x? We have many features that have to evolve. Snapshots, rebalance, tooling, tracing, zookeeper support, etc. We have bugs and issues that can be fixed in 2.x without breaking backward compatibility. We have many users who are happy with the 2.x with all it’s issues. > 2 нояб. 2020 г., в 14:09, Anton Vinogradov <a...@apache.org> написал(а): > > Alexey, > > Do we have any estimates of how fast we'll be able to gain production-ready > AI 3.0 in case of a "new repo" choice? > > On Mon, Nov 2, 2020 at 2:01 PM Alexey Goncharuk <alexey.goncha...@gmail.com> > wrote: > >> Nikolay, >> >> What new features are we planning to implement for Ignite 2.x? I think once >> we commence working on Ignite 3.0, we should gradually cease the activity >> on Ignite 2.x to mere bugfixes because such parallel development will be >> overwhelming regardless of how we choose to proceed. >> >> пн, 2 нояб. 2020 г. в 13:38, Nikolay Izhikov <nizhi...@apache.org>: >> >>> To be clear: >>> >>>> I would suggest creating a new repository for Ignite 3.0 (perhaps, a >> new >>> clean branch, but a new repo looks nicer to me) and a new Ignite 3.0 >>> TeamCity project. >>> >>> +1 for new Team City project. >>> +1 for new branch for Ignite3. >>> -1 for new repo. >>> >>> >>>> 2 нояб. 2020 г., в 13:35, Nikolay Izhikov <nizhikov....@gmail.com> >>> написал(а): >>>> >>>> Hello, Alexey. >>>> >>>> I think it will hurt our project more than help. >>>> Developing new features for 2 separate branches with the different APIs >>> and internal structure is overwhelming >>>> >>>> Maybe we should relax a bit requirements for Ignite3? >>>> Maybe we should move step by step and make Ignite3 with new >>> configuration than Ignite4 with new transactions, etc? >>>> >>>>> 2 нояб. 2020 г., в 13:14, Alexey Goncharuk < >> alexey.goncha...@gmail.com> >>> написал(а): >>>>> >>>>> Igniters, >>>>> >>>>> I wanted to pitch a rather radical idea regarding the Ignite 3.0 >>>>> development which has occurred to me some time ago. >>>>> >>>>> We already have several IEPs targeted to Ignite 3.0 which imply major >>>>> changes to the codebase (the change in replication protocol and thus >>>>> transactions, change in binary format, updated metastorage, etc). We >>> also >>>>> planned significant changes in public APIs: configuration format >> change, >>>>> improvements in cache APIs, SQL APIs, transaction mode rework. The >>> wishlist >>>>> of changes for Ignite 3.0 is huge. >>>>> >>>>> So, I was wondering whether it makes sense to try to change the old >>>>> codebase, or start with a new baseline and move old pieces of code >> that >>> do >>>>> not require significant rework. Personally, I would go with the second >>>>> option for the following reasons: >>>>> >>>>> - We have a chance to shift the development paradigm in the project >> and >>>>> introduce the practice of true unit-tests. In the new baseline at the >>>>> beginning there will be no ability to run an end-to-end scenario, >> thus >>> we >>>>> will be forced to write unit-tests. So far, such practice was hard to >>>>> implement because of tight coupling between Ignite components and >>> inability >>>>> to instantiate components without an instance of KernalContext. For >>>>> example, we should be able to thoroughly test internal primitives, >>> such as >>>>> replication protocol (without actual communication), distributed >>>>> metastorage contracts, persistence layer, etc. >>>>> - We will significantly reduce the development cycle in the beginning >>>>> (right now the RunAll takes two hours of astronomical time with empty >>> TC; >>>>> in the new approach developer will be able to run ALL tests locally >> in >>> a >>>>> matter of minutes) >>>>> - We can get rid of TC bot and enforce green TC by integrating TC >> build >>>>> results with GitHub PRs (the same way Travis is currently integrated >>> to PR >>>>> check). We should restrict PR merge without a TC check >>>>> - We will still have to re-write all tests, but only once. If we try >> to >>>>> modify the old codebase, we would need to modify all the tests for >>> every >>>>> major change (public API change, configuration change) >>>>> - We will have fewer conflicts when working together. For example, I >>>>> cannot imagine how one would merge two changes of getting rid of >>>>> IgniteFuture and changes in replication protocol, for example >>>>> >>>>> Technically, I would suggest creating a new repository for Ignite 3.0 >>>>> (perhaps, a new clean branch, but a new repo looks nicer to me) and a >>> new >>>>> Ignite 3.0 TeamCity project. >>>>> >>>>> While it may seem quite radical, I do believe that this approach will >>> give >>>>> us more benefits than trying to make such major changes in the >> existing >>>>> codebase. If needed, let's schedule a discord chat like before to >>> discuss >>>>> this. >>>>> >>>>> WDYT? >>>> >>> >>> >>
