Hello, Alexei Thanks for feedback.
> Removing some deprecated features and releasing it as Ignite 3.0 doesn’t make > sense to me. > This should be done in Ignite 2.X, but mostly (except MVCC) looks like a > waste of time to me. But we have a big wish list that we want to remove from Ignite in the next major version. Do you believe it useless for Ignite and Ignite users? > Such a release has no value for a user, because actually it's 2.X. I think we can provide more stability and easy to use if remove obsolete parts of Ignite code. > Because 3.0 is started from scratch This statement is controversial with statements we discussed in the Ignite-3 thread [2] Alexey Goncharuk > First of all, I wanted to stress that I do not intend to rewrite everything from scratch [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist [2] http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html > 9 марта 2021 г., в 20:47, Maxim Muzafarov <mmu...@apache.org> написал(а): > > Alexei, > > > Thank you for sharing details with the progress in the ignite-3 > development with the Community. > > I would like to believe in the best with the distribution database > development, but please do not forget our previous experience with the > 2.x version: > - it took years to make the Ignite production-ready and finally, it > became like that > - please note that bad fame is very hard to fix, so the developed but > not well-tested source code may scare away some users > - as a developer, I also really enjoy working on breakthrough > technologies, but It's very sad to hear reviews about instability and > data loss > - take into account the resource management - some developers may or > may not be switched to different projects (you also know examples of > this) > - take into account the MVCC and Calcite features wich much smaller > than the changes submitted to ignite-3 and still not finished > completely > > According to all of these points above, I can't share your optimism > and propose to go through my suggested `evolutionary changes` with the > next release. > > On Tue, 9 Mar 2021 at 20:14, Alexei Scherbakov > <alexey.scherbak...@gmail.com> wrote: >> >> -1. >> >> Removing some deprecated features and releasing it as Ignite 3.0 doesn't >> make sense to me. >> This should be done in Ignite 2.X, but mostly (except MVCC) looks like a >> waste of time to me. >> Such a release has no value for a user, because actually it's 2.X. >> Because 3.0 is started from scratch, it will not contain deprecated >> features by definition. >> >> Releasing Ignite 4.0, 5.0 etc doesn't make any sense to me as well. >> Upgrading to a "grand" release is always a big trouble and we shouldn't >> make such releases as pies. >> We have already discussed and agreed on a list of release driver IEPs like >> IEP-54, IEP-55, IEP-61 and should stick to it for 3.0. >> >> Moveover, there is already a big progress on raft protocol implementation >> in 3.0 (IEP-61), as well as other features, and I'm going to make a >> public update on this topic in the next few days. >> >> The estimation in years to finish 3.0 looks too huge to me, actually it >> should be finished by the end of the year. >> >> вт, 9 мар. 2021 г. в 19:53, Maxim Muzafarov <mmu...@apache.org>: >> >>> Pavel, >>> >>>> We have agreed on a direction for 3.0 [1], no need to change it. >>> >>> Thank you for sharing the link, but there is no agreement on that >>> thread. The Community even not vote in that direction, so I think we >>> can consider another option here. >>> >>> On Tue, 9 Mar 2021 at 19:46, Pavel Tupitsyn <ptupit...@apache.org> wrote: >>>> >>>> -1 >>>> >>>> We have agreed on a direction for 3.0 [1], no need to change it. >>>> >>>> [1] >>>> >>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html >>>> >>>> On Tue, Mar 9, 2021 at 7:42 PM Maxim Muzafarov <mmu...@apache.org> >>> wrote: >>>> >>>>> Pavel, >>>>> >>>>>> 2) Much later, release what is being worked on in ignite-3 as Ignite >>> 4.0 >>>>> or 5.0 >>>>> >>>>> Yes, you're right. >>>>> >>>>> On Tue, 9 Mar 2021 at 19:41, Maxim Muzafarov <mmu...@apache.org> >>> wrote: >>>>>> >>>>>> Ilya, >>>>>> >>>>>>> 0. I am accustomed with major.minor.maintenance schema. Does it >>> make >>>>> any difference? >>>>>> >>>>>> There is no difference without a small note that from my point of >>> view >>>>>> minor releases 2.7 > 2.8 > 2.9 by the amount of changes are not so >>>>>> 'minor'. >>>>>> >>>>>>> 2. What's `lock'? >>>>>> >>>>>> I'm talking about some public and marketing activities with 3.0 >>>>>> version which happened some time ago [1]. I don't think they can >>>>>> really block the proposed release but at least it should be discussed >>>>>> how we should promote the new release. >>>>>> >>>>>>> 3. I don't see why there would be implicit PDS compatibility >>> between >>>>> any X.0.0 and Y.0.0, X != Y. >>>>>> >>>>>> Yes, in general, we can't guarantee the PDS compatibility. I propose >>>>>> the following steps: >>>>>> - the next release (3.0) should be without PDS compatibility issues, >>>>>> so users will be able to start their cluster on the same data files >>> or >>>>>> even migrating to the next release without any problems if they don't >>>>>> use deprecated features. >>>>>> - if any next releases (e.g. 4.0) will introduce such issues we >>> should >>>>>> provide migration scripts. >>>>>> >>>>>> >>>>>> [1] >>>>> >>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process#IEP69:Theevolutionaryreleaseprocess-RisksandAssumptions >>>>>> >>>>>> On Tue, 9 Mar 2021 at 19:30, Pavel Tupitsyn <ptupit...@apache.org> >>>>> wrote: >>>>>>> >>>>>>> Maxim, >>>>>>> >>>>>>> What you propose is >>>>>>> >>>>>>> 1) Take Ignite 2.x, remove some deprecated features, and release >>> that >>>>> as >>>>>>> Ignite 3.0 >>>>>>> 2) Much later, release what is being worked on in ignite-3 as >>> Ignite >>>>> 4.0 or >>>>>>> 5.0 >>>>>>> >>>>>>> Do I understand this correctly? >>>>>>> >>>>>>> On Tue, Mar 9, 2021 at 7:15 PM Ilya Kasnacheev < >>>>> ilya.kasnach...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hello! >>>>>>>> >>>>>>>> 0. I am accustomed with major.minor.maintenance schema. Does it >>> make >>>>> any >>>>>>>> difference? >>>>>>>> 2. What's `lock'? >>>>>>>> 3. I don't see why there would be implicit PDS compatibility >>> between >>>>> any >>>>>>>> X.0.0 and Y.0.0, X != Y. >>>>>>>> 4. I think this is a sensible approach. >>>>>>>> 5. Since ignite-3 seems to be a separate repo ATM, I don't see >>> why >>>>> it is >>>>>>>> applicable. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> -- >>>>>>>> Ilya Kasnacheev >>>>>>>> >>>>>>>> >>>>>>>> пт, 5 мар. 2021 г. в 22:09, Maxim Muzafarov <mmu...@apache.org>: >>>>>>>> >>>>>>>>> Ignites, >>>>>>>>> >>>>>>>>> >>>>>>>>> I've created the IEP-69 [1] which describes the evolutionary >>>>> release >>>>>>>>> process for the Apache Ignite 2.x version. You can find all the >>>>>>>>> details of my suggestion there, but here you can find the >>> crucial >>>>>>>>> points: >>>>>>>>> >>>>>>>>> 0. Versioning - grand.major.bug-fix[-rc_number] >>>>>>>>> >>>>>>>>> 1. Prepare the next 3.0 release based on 2.x with some breaking >>>>>>>>> compatibility changes. The same things happen from time to time >>>>> with >>>>>>>>> other Apache projects like Hadoop, Spark. >>>>>>>>> >>>>>>>>> 2. Discuss with the whole Community and assign the right >>> release >>>>>>>>> version to the activities related to the development of the new >>>>> Ignite >>>>>>>>> architecture (currently all the changes you can find in the >>>>> ignite-3 >>>>>>>>> branch). >>>>>>>>> I see no 3.0 discussions on the dev-list and I see no-activity >>> with >>>>>>>>> the 3.0 version currently. So, it's better to remove the >>> `lock` >>>>> from >>>>>>>>> the 3.0 version and allow the removal of obsolete features. >>>>>>>>> >>>>>>>>> 3. Guarantee the PDS compatibility between the `grand` >>> versions of >>>>> the >>>>>>>>> Apache Ignite for the next year. >>>>>>>>> >>>>>>>>> 4. Guarantee the bug-fix release for the last 2.x Apache Ignite >>>>>>>>> version for the next year. >>>>>>>>> >>>>>>>>> 5. Perform some improvements which break the backward >>>>> compatibility, >>>>>>>>> for instance: removing @deprecated API (except metrics), >>> removing >>>>>>>>> obsolete modules, changing the cluster defaults. You can find >>>>>>>>> additional details on the IEP-69 page [1]. >>>>>>>>> >>>>>>>>> >>>>>>>>> Please, share your thoughts. >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>>>>>> >>>>> >>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process >>>>>>>>> >>>>>>>> >>>>> >>> >> >> >> -- >> >> Best regards, >> Alexei Scherbakov
