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?
