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

Reply via email to