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? >
