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