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