You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Maxim Muzafarov <mm...@apache.org> on 2021/03/05 19:08:52 UTC

[DISCUSSION] IEP-69 The evolutionary release process

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

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Denis Magda <dm...@apache.org>.
Folks,

You all are going in circles, and the fact that we started another
discussion thread in addition to the following one [1] won't help to bring
us together. Presently it's black and white, polarized opinions. Go and
talk. Verbally. Come up with a common ground.


[1]
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
<http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html>
-
Denis


On Fri, Mar 5, 2021 at 1:09 PM Maxim Muzafarov <mm...@apache.org> wrote:

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

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Maxim Muzafarov <mm...@apache.org>.
Hi Pavel,


I don't think the `against` is the right word here. Those changes must
be released for sure, however, I don't think it good for the current
state of the Ignite codebase to `lock` the 3.0 version for years
without any guarantees. Probably, we should assign the right Ignite
version for the ignite-3 project when the changes will be ready and
well tested.

I've described the risks on the wiki page [1].

[1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process#IEP69:Theevolutionaryreleaseprocess-RisksandAssumptions

On Tue, 9 Mar 2021 at 16:23, Pavel Tupitsyn <pt...@apache.org> wrote:
>
> Maxim,
>
> This proposal goes against [1], as I understand.
> Ignite 3.0 development is going on in [2]
>
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> [2] https://github.com/apache/ignite-3
>
> On Sun, Mar 7, 2021 at 11:04 AM Nikolay Izhikov <ni...@apache.org> wrote:
>
> > Hello, Maxim.
> >
> > I’m +1 to follow your proposal.
> >
> > > 5 марта 2021 г., в 22:08, Maxim Muzafarov <mm...@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
> >
> >

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Pavel Tupitsyn <pt...@apache.org>.
Maxim,

This proposal goes against [1], as I understand.
Ignite 3.0 development is going on in [2]

[1]
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
[2] https://github.com/apache/ignite-3

On Sun, Mar 7, 2021 at 11:04 AM Nikolay Izhikov <ni...@apache.org> wrote:

> Hello, Maxim.
>
> I’m +1 to follow your proposal.
>
> > 5 марта 2021 г., в 22:08, Maxim Muzafarov <mm...@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
>
>

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Maxim.

I’m +1 to follow your proposal.

> 5 марта 2021 г., в 22:08, Maxim Muzafarov <mm...@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

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Petr Ivanov <mr...@gmail.com>.
Maksim,


Great summary!
+1 for versioning scheme.


However, deprecation rules can be possibly misleading.
I think that we should use 'since' as a mandatory annotation, that will mark the release where the API can (not should) be changed, regardless of our intention to modify it.
And add some kind of a tag or alike to that APIs only that we need to update/remove since mentioned release.
Otherwise, I think, simple deprecation annotation will raise questions 'when it was deprecated' or 'is it already time to update/remove deprecated API'.

Also, if agreed on 'since' annotation usage, we possibly should create the issue to tag all current deprecated APIs with since where applicable.

> On 16 Mar 2021, at 21:05, Maxim Muzafarov <mm...@apache.org> wrote:
> 
> Folks,
> 
> 
> Thanks to everyone for participating in the call. Here is the list of
> points we've agreed on and the list of actions which should be
> discussed in more details.
> 
> 
> = AGREED =
> 
> == Versioning ==
> 
> grand.major.bugfix[-rc_number]
> 
> The 'grand' version is fixed while both Ignite architectures (current
> version 2.x and 3.x) are in a state of active development/maintained
> or until otherwise is discussed further. This means:
> - the master branch of the ignite repository [2] always release under
> the '2.x.x' version
> - the main branch of the ignite-3 repository [1] always release under
> the '3.x.x' version
> 
> The 'major' versions for each architecture may contain breaking
> backwards compatibility changes compared to the previous one if the
> following criteria are met:
> - users should be warned about breaking release changes (the ways of
> notification should be additionally discussed and agreed upon)
> - the deprecation rules may be applied for the current 'major' release
> (the ways of deprecation must be additionally discussed and agreed
> upon)
> - current @deprecated already have enough time live and some of them
> can be removed using common sense
> 
> The 'bugfix' version is used for emergency releases and can't contain
> any breaking backwards compatibility changes.
> 
> == Commitments ==
> 
> Any commitment to support previous releases (e.g. 1 year, 1 quarter)
> have no sense to the open-source Ignite community in the case of
> observed backward compatibility violations, however, in any of such
> cases, an emergency release can be performed according to the accepted
> release procedure.
> 
> 
> = DISCUSSION & SUGGESTIONS =
> 
> 
> == Deprecation rules ==
> 
> The API deprecation rules must be discussed and agreed upon in more
> details. The list of options we have:
> - deprecate and remove API allowed in the next release
> - deprecate and remove API allowed through the one release
> - deprecation may contain comments - the release version then the API
> will be changed
> - deprecation may contain comments - the date from which the API changes allowed
> 
> I've checked the `JEP 277 Enhanced Deprecation` [3] proposal which
> adds the `forRemoval` and `since` optional elements to the deprecated
> annotation and I think we can use a similar approach here with some
> additions. For instance, if the last released version is 2.10 my
> suggestions would be the following:
> - [case: change API as quickly as possible] mark some API as
> deprecated, set 'since' version 2.12, change it in the 2.12 release
> major version.
> - [case: deprecate API without intention to change] mark API as
> deprecated without 'since' options, change it without notifications
> since 2.13 releases and so on.
> 
> 
> == User notification rules ==
> 
> Uses must be well-notified about the planned backward compatibility
> violations. The options we have:
> - the notification thought the source code with well-described JavaDocs
> - add labels to the JIRA issue if some deprecations occur in the related patch
> - add deprecation and backward compatibility paragraph to the RELEASE_NOTES
> - add a page to the Apache Ignite website with a backwards
> compatibility description between the closest versions
> 
> All of the above must be done.
> 
> 
> == Experimental and unstable APIs ==
> 
> The options we have:
> - only the new API can be marked as unstable and/or experimental
> - such APIs can be changed without any notifications
> 
> 
> Please, share your thoughts.
> 
> 
> [1] https://github.com/apache/ignite-3
> [2] https://github.com/apache/ignite
> [3] https://openjdk.java.net/jeps/277
> 
> On Mon, 15 Mar 2021 at 19:41, Dmitriy Pavlov <dp...@apache.org> wrote:
>> 
>> Folks,
>> 
>> let me add my 50 cents. I don't see major issues with this IEP, for now.
>> And I really looking forward to talking about it. I can't get what causes
>> misunderstanding.
>> 
>> The only thing that concerns me here is that IEP requires the community to
>> support solutions for 1 year, 1 quarter, etc.
>> 
>> Apache community is not a commercial company that provides support of any
>> kind, and I would be reluctant to add these or similar statements to any
>> public documents. At any point in time, the community and PMC can vote and
>> introduce any major feature breaking compatibility. We tend to avoid such
>> actions to keep users best interest. But it is not a commitment.
>> 
>> Sincerely
>> 
>> 
>> чт, 11 мар. 2021 г. в 23:11, Maxim Muzafarov <mm...@apache.org>:
>> 
>>> Val,
>>> 
>>> 
>>> I'm sorry if anything from what I've said sounded disrespectful. All
>>> of you are examples for me to follow :-)
>>> 
>>> Have you checked the `motivation` [1] topic on the IEP-69 page? Should
>>> I add more details to it prior to the call? I want to make Ignite
>>> better and also think that the current 2.x version with all the
>>> advantages and disadvantages is far from exhausted its capabilities.
>>> I'm pretty sure the same motivation page exists for 3.0 version
>>> describing the advantages and disadvantages of developing mentioned
>>> IEPs. It will be good to share it prior to the cal also.
>>> 
>>> 
>>> [1]
>>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process#IEP69:Theevolutionaryreleaseprocess-Motivation
>>> 
>>> On Thu, 11 Mar 2021 at 01:21, Valentin Kulichenko
>>> <va...@gmail.com> wrote:
>>>> 
>>>> Ksenya, thanks for scheduling this so quickly!
>>>> 
>>>> Guys, I hope we can make this discussion constructive. Please keep in
>>> mind
>>>> that Ignite 3 is an ongoing project supported by multiple contributors,
>>>> committers, and PMC members. Neglecting 6+ months of effort and
>>> suggesting
>>>> that it's just "prototyping some cool features and nothing more" is
>>> really
>>>> bizarre, and, quite frankly, sounds disrespectful to fellow developers
>>>> (although I'm 100% sure it was not intended this way).
>>>> 
>>>> Maxim, one of the biggest issues I have with your IEP is that I don't
>>>> understand the motivation behind it. If you don't mind, I would like to
>>>> suggest that you kick off the meeting with a detailed explanation
>>>> of exactly that. The first step is to achieve a mutual understanding of
>>>> each other's goals. Once we do that, I'm sure we will easily find a
>>>> solution.
>>>> 
>>>> -Val
>>>> 
>>>> On Wed, Mar 10, 2021 at 8:55 AM Kseniya Romanova <
>>> romanova.ks.spb@gmail.com>
>>>> wrote:
>>>> 
>>>>> Let's make a quick call next week and try to find a compromise which
>>> can
>>>>> get the process moving:
>>>>> https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/276851588/
>>>>> 
>>>>> ср, 10 мар. 2021 г. в 16:27, Maxim Muzafarov <mm...@apache.org>:
>>>>> 
>>>>>> Folks,
>>>>>> 
>>>>>> 
>>>>>> Agree, the discussion may be endless without compromises on all
>>> sides.
>>>>>> I always think that if there is no consensus (and I see from the
>>>>>> thread [1] that it's was no found) for such important decisions like
>>>>>> product future development and releases AFS provides the voting
>>>>>> procedure. Without fixing the results of the discussion [1] it sounds
>>>>>> like prototyping some cool features and nothing more.
>>>>>> 
>>>>>> So, back to Denis suggestion can you share - what would be the best
>>>>>> time for all of us (considering different time zones) to have a call?
>>>>>> 
>>>>>> I also think that we should start a vote about the future releases on
>>>>>> our Apache Ignite web-site and user-list, thus all who are using the
>>>>>> Apache Ignite may choose the best option they like.
>>>>>> 
>>>>>> 
>>>>>> [1]
>>>>>> 
>>>>> 
>>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
>>>>>> 
>>>>>> On Wed, 10 Mar 2021 at 03:57, Valentin Kulichenko
>>>>>> <va...@gmail.com> wrote:
>>>>>>> 
>>>>>>> Hi Maxim,
>>>>>>> 
>>>>>>> I disagree with the suggestions. Several community members have
>>> already
>>>>>>> pointed out the discussion about Ignite 3.0 [1]. During that
>>>>> discussion,
>>>>>> we
>>>>>>> did agree on the scope of the changes for 3.0, as well as the
>>> general
>>>>>>> direction for the product. The new repo was created not to "develop
>>>>> from
>>>>>>> scratch", but to provide an opportunity for the community members
>>> to
>>>>>>> actively work on Ignite 3 without killing the Ignite 2.x. No
>>>>> alternative
>>>>>>> solution for this was presented, so we went ahead with the process
>>> -- I
>>>>>>> consider that to be an example of the silent consensus.
>>>>>>> 
>>>>>>> I also want to emphasize that Ignite 3 is active and is moving
>>> forward.
>>>>>> If
>>>>>>> you look at the ignite-3 repo, commits and PRs are coming in on
>>> regular
>>>>>>> basis. We also had the first alpha release early in the year. I do
>>>>> agree
>>>>>>> with you, however, that there is not too much activity on the dev
>>> list.
>>>>>> As
>>>>>>> far as I can tell, the main reason for this is that communication
>>> moved
>>>>>> to
>>>>>>> IEPs and GitHub PRs, for better or worse. This is something we all
>>> can
>>>>>> talk
>>>>>>> about -- I personally would like to see more discussions on the dev
>>>>> list.
>>>>>>> 
>>>>>>> And finally, I agree with Denis. This whole situation is
>>>>>>> counter-productive. I'm happy to jump on a Discord or any other
>>> voice
>>>>>> chat
>>>>>>> to discuss in more detail.
>>>>>>> 
>>>>>>> [1]
>>>>>>> 
>>>>>> 
>>>>> 
>>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
>>>>>>> 
>>>>>>> -Val
>>>>>>> 
>>>>>>> On Fri, Mar 5, 2021 at 11:09 AM Maxim Muzafarov <mmuzaf@apache.org
>>>> 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> 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
>>>>>>>> 
>>>>>> 
>>>>> 
>>>

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Steshin Vladimir <vl...@gmail.com>.
     Maxim, Folks, hi.

The approach looks reasonable to me, +1

As an additional user notification, we might use even/odd number 
strategy. User could be sure that even (as an example) major release 
doesn’t break backward compatibility. Crucial API changes might be 
collected only in odd releases. Moreover, odd majors might be omitted at 
all in case of absence of compatibility breach.

16.03.2021 21:05, Maxim Muzafarov пишет:
> Folks,
>
>
> Thanks to everyone for participating in the call. Here is the list of
> points we've agreed on and the list of actions which should be
> discussed in more details.
>
>
> = AGREED =
>
> == Versioning ==
>
> grand.major.bugfix[-rc_number]
>
> The 'grand' version is fixed while both Ignite architectures (current
> version 2.x and 3.x) are in a state of active development/maintained
> or until otherwise is discussed further. This means:
> - the master branch of the ignite repository [2] always release under
> the '2.x.x' version
> - the main branch of the ignite-3 repository [1] always release under
> the '3.x.x' version
>
> The 'major' versions for each architecture may contain breaking
> backwards compatibility changes compared to the previous one if the
> following criteria are met:
> - users should be warned about breaking release changes (the ways of
> notification should be additionally discussed and agreed upon)
> - the deprecation rules may be applied for the current 'major' release
> (the ways of deprecation must be additionally discussed and agreed
> upon)
> - current @deprecated already have enough time live and some of them
> can be removed using common sense
>
> The 'bugfix' version is used for emergency releases and can't contain
> any breaking backwards compatibility changes.
>
> == Commitments ==
>
> Any commitment to support previous releases (e.g. 1 year, 1 quarter)
> have no sense to the open-source Ignite community in the case of
> observed backward compatibility violations, however, in any of such
> cases, an emergency release can be performed according to the accepted
> release procedure.
>
>
> = DISCUSSION & SUGGESTIONS =
>
>
> == Deprecation rules ==
>
> The API deprecation rules must be discussed and agreed upon in more
> details. The list of options we have:
> - deprecate and remove API allowed in the next release
> - deprecate and remove API allowed through the one release
> - deprecation may contain comments - the release version then the API
> will be changed
> - deprecation may contain comments - the date from which the API changes allowed
>
> I've checked the `JEP 277 Enhanced Deprecation` [3] proposal which
> adds the `forRemoval` and `since` optional elements to the deprecated
> annotation and I think we can use a similar approach here with some
> additions. For instance, if the last released version is 2.10 my
> suggestions would be the following:
> - [case: change API as quickly as possible] mark some API as
> deprecated, set 'since' version 2.12, change it in the 2.12 release
> major version.
> - [case: deprecate API without intention to change] mark API as
> deprecated without 'since' options, change it without notifications
> since 2.13 releases and so on.
>
>
> == User notification rules ==
>
> Uses must be well-notified about the planned backward compatibility
> violations. The options we have:
> - the notification thought the source code with well-described JavaDocs
> - add labels to the JIRA issue if some deprecations occur in the related patch
> - add deprecation and backward compatibility paragraph to the RELEASE_NOTES
> - add a page to the Apache Ignite website with a backwards
> compatibility description between the closest versions
>
> All of the above must be done.
>
>
> == Experimental and unstable APIs ==
>
> The options we have:
> - only the new API can be marked as unstable and/or experimental
> - such APIs can be changed without any notifications
>
>
> Please, share your thoughts.
>
>
> [1] https://github.com/apache/ignite-3
> [2] https://github.com/apache/ignite
> [3] https://openjdk.java.net/jeps/277
>
> On Mon, 15 Mar 2021 at 19:41, Dmitriy Pavlov <dp...@apache.org> wrote:
>> Folks,
>>
>> let me add my 50 cents. I don't see major issues with this IEP, for now.
>> And I really looking forward to talking about it. I can't get what causes
>> misunderstanding.
>>
>> The only thing that concerns me here is that IEP requires the community to
>> support solutions for 1 year, 1 quarter, etc.
>>
>> Apache community is not a commercial company that provides support of any
>> kind, and I would be reluctant to add these or similar statements to any
>> public documents. At any point in time, the community and PMC can vote and
>> introduce any major feature breaking compatibility. We tend to avoid such
>> actions to keep users best interest. But it is not a commitment.
>>
>> Sincerely
>>
>>
>> чт, 11 мар. 2021 г. в 23:11, Maxim Muzafarov <mm...@apache.org>:
>>
>>> Val,
>>>
>>>
>>> I'm sorry if anything from what I've said sounded disrespectful. All
>>> of you are examples for me to follow :-)
>>>
>>> Have you checked the `motivation` [1] topic on the IEP-69 page? Should
>>> I add more details to it prior to the call? I want to make Ignite
>>> better and also think that the current 2.x version with all the
>>> advantages and disadvantages is far from exhausted its capabilities.
>>> I'm pretty sure the same motivation page exists for 3.0 version
>>> describing the advantages and disadvantages of developing mentioned
>>> IEPs. It will be good to share it prior to the cal also.
>>>
>>>
>>> [1]
>>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process#IEP69:Theevolutionaryreleaseprocess-Motivation
>>>
>>> On Thu, 11 Mar 2021 at 01:21, Valentin Kulichenko
>>> <va...@gmail.com> wrote:
>>>> Ksenya, thanks for scheduling this so quickly!
>>>>
>>>> Guys, I hope we can make this discussion constructive. Please keep in
>>> mind
>>>> that Ignite 3 is an ongoing project supported by multiple contributors,
>>>> committers, and PMC members. Neglecting 6+ months of effort and
>>> suggesting
>>>> that it's just "prototyping some cool features and nothing more" is
>>> really
>>>> bizarre, and, quite frankly, sounds disrespectful to fellow developers
>>>> (although I'm 100% sure it was not intended this way).
>>>>
>>>> Maxim, one of the biggest issues I have with your IEP is that I don't
>>>> understand the motivation behind it. If you don't mind, I would like to
>>>> suggest that you kick off the meeting with a detailed explanation
>>>> of exactly that. The first step is to achieve a mutual understanding of
>>>> each other's goals. Once we do that, I'm sure we will easily find a
>>>> solution.
>>>>
>>>> -Val
>>>>
>>>> On Wed, Mar 10, 2021 at 8:55 AM Kseniya Romanova <
>>> romanova.ks.spb@gmail.com>
>>>> wrote:
>>>>
>>>>> Let's make a quick call next week and try to find a compromise which
>>> can
>>>>> get the process moving:
>>>>> https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/276851588/
>>>>>
>>>>> ср, 10 мар. 2021 г. в 16:27, Maxim Muzafarov <mm...@apache.org>:
>>>>>
>>>>>> Folks,
>>>>>>
>>>>>>
>>>>>> Agree, the discussion may be endless without compromises on all
>>> sides.
>>>>>> I always think that if there is no consensus (and I see from the
>>>>>> thread [1] that it's was no found) for such important decisions like
>>>>>> product future development and releases AFS provides the voting
>>>>>> procedure. Without fixing the results of the discussion [1] it sounds
>>>>>> like prototyping some cool features and nothing more.
>>>>>>
>>>>>> So, back to Denis suggestion can you share - what would be the best
>>>>>> time for all of us (considering different time zones) to have a call?
>>>>>>
>>>>>> I also think that we should start a vote about the future releases on
>>>>>> our Apache Ignite web-site and user-list, thus all who are using the
>>>>>> Apache Ignite may choose the best option they like.
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>>
>>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
>>>>>> On Wed, 10 Mar 2021 at 03:57, Valentin Kulichenko
>>>>>> <va...@gmail.com> wrote:
>>>>>>> Hi Maxim,
>>>>>>>
>>>>>>> I disagree with the suggestions. Several community members have
>>> already
>>>>>>> pointed out the discussion about Ignite 3.0 [1]. During that
>>>>> discussion,
>>>>>> we
>>>>>>> did agree on the scope of the changes for 3.0, as well as the
>>> general
>>>>>>> direction for the product. The new repo was created not to "develop
>>>>> from
>>>>>>> scratch", but to provide an opportunity for the community members
>>> to
>>>>>>> actively work on Ignite 3 without killing the Ignite 2.x. No
>>>>> alternative
>>>>>>> solution for this was presented, so we went ahead with the process
>>> -- I
>>>>>>> consider that to be an example of the silent consensus.
>>>>>>>
>>>>>>> I also want to emphasize that Ignite 3 is active and is moving
>>> forward.
>>>>>> If
>>>>>>> you look at the ignite-3 repo, commits and PRs are coming in on
>>> regular
>>>>>>> basis. We also had the first alpha release early in the year. I do
>>>>> agree
>>>>>>> with you, however, that there is not too much activity on the dev
>>> list.
>>>>>> As
>>>>>>> far as I can tell, the main reason for this is that communication
>>> moved
>>>>>> to
>>>>>>> IEPs and GitHub PRs, for better or worse. This is something we all
>>> can
>>>>>> talk
>>>>>>> about -- I personally would like to see more discussions on the dev
>>>>> list.
>>>>>>> And finally, I agree with Denis. This whole situation is
>>>>>>> counter-productive. I'm happy to jump on a Discord or any other
>>> voice
>>>>>> chat
>>>>>>> to discuss in more detail.
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
>>>>>>> -Val
>>>>>>>
>>>>>>> On Fri, Mar 5, 2021 at 11:09 AM Maxim Muzafarov <mmuzaf@apache.org
>>>>>> wrote:
>>>>>>>> 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

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Valentin Kulichenko <va...@gmail.com>.
Hi Maxim,

Thanks for summarizing. +1 for the versioning scheme.

-Val

On Tue, Mar 16, 2021 at 11:05 AM Maxim Muzafarov <mm...@apache.org> wrote:

> Folks,
>
>
> Thanks to everyone for participating in the call. Here is the list of
> points we've agreed on and the list of actions which should be
> discussed in more details.
>
>
> = AGREED =
>
> == Versioning ==
>
> grand.major.bugfix[-rc_number]
>
> The 'grand' version is fixed while both Ignite architectures (current
> version 2.x and 3.x) are in a state of active development/maintained
> or until otherwise is discussed further. This means:
> - the master branch of the ignite repository [2] always release under
> the '2.x.x' version
> - the main branch of the ignite-3 repository [1] always release under
> the '3.x.x' version
>
> The 'major' versions for each architecture may contain breaking
> backwards compatibility changes compared to the previous one if the
> following criteria are met:
> - users should be warned about breaking release changes (the ways of
> notification should be additionally discussed and agreed upon)
> - the deprecation rules may be applied for the current 'major' release
> (the ways of deprecation must be additionally discussed and agreed
> upon)
> - current @deprecated already have enough time live and some of them
> can be removed using common sense
>
> The 'bugfix' version is used for emergency releases and can't contain
> any breaking backwards compatibility changes.
>
> == Commitments ==
>
> Any commitment to support previous releases (e.g. 1 year, 1 quarter)
> have no sense to the open-source Ignite community in the case of
> observed backward compatibility violations, however, in any of such
> cases, an emergency release can be performed according to the accepted
> release procedure.
>
>
> = DISCUSSION & SUGGESTIONS =
>
>
> == Deprecation rules ==
>
> The API deprecation rules must be discussed and agreed upon in more
> details. The list of options we have:
> - deprecate and remove API allowed in the next release
> - deprecate and remove API allowed through the one release
> - deprecation may contain comments - the release version then the API
> will be changed
> - deprecation may contain comments - the date from which the API changes
> allowed
>
> I've checked the `JEP 277 Enhanced Deprecation` [3] proposal which
> adds the `forRemoval` and `since` optional elements to the deprecated
> annotation and I think we can use a similar approach here with some
> additions. For instance, if the last released version is 2.10 my
> suggestions would be the following:
> - [case: change API as quickly as possible] mark some API as
> deprecated, set 'since' version 2.12, change it in the 2.12 release
> major version.
> - [case: deprecate API without intention to change] mark API as
> deprecated without 'since' options, change it without notifications
> since 2.13 releases and so on.
>
>
> == User notification rules ==
>
> Uses must be well-notified about the planned backward compatibility
> violations. The options we have:
> - the notification thought the source code with well-described JavaDocs
> - add labels to the JIRA issue if some deprecations occur in the related
> patch
> - add deprecation and backward compatibility paragraph to the RELEASE_NOTES
> - add a page to the Apache Ignite website with a backwards
> compatibility description between the closest versions
>
> All of the above must be done.
>
>
> == Experimental and unstable APIs ==
>
> The options we have:
> - only the new API can be marked as unstable and/or experimental
> - such APIs can be changed without any notifications
>
>
> Please, share your thoughts.
>
>
> [1] https://github.com/apache/ignite-3
> [2] https://github.com/apache/ignite
> [3] https://openjdk.java.net/jeps/277
>
> On Mon, 15 Mar 2021 at 19:41, Dmitriy Pavlov <dp...@apache.org> wrote:
> >
> > Folks,
> >
> > let me add my 50 cents. I don't see major issues with this IEP, for now.
> > And I really looking forward to talking about it. I can't get what causes
> > misunderstanding.
> >
> > The only thing that concerns me here is that IEP requires the community
> to
> > support solutions for 1 year, 1 quarter, etc.
> >
> > Apache community is not a commercial company that provides support of any
> > kind, and I would be reluctant to add these or similar statements to any
> > public documents. At any point in time, the community and PMC can vote
> and
> > introduce any major feature breaking compatibility. We tend to avoid such
> > actions to keep users best interest. But it is not a commitment.
> >
> > Sincerely
> >
> >
> > чт, 11 мар. 2021 г. в 23:11, Maxim Muzafarov <mm...@apache.org>:
> >
> > > Val,
> > >
> > >
> > > I'm sorry if anything from what I've said sounded disrespectful. All
> > > of you are examples for me to follow :-)
> > >
> > > Have you checked the `motivation` [1] topic on the IEP-69 page? Should
> > > I add more details to it prior to the call? I want to make Ignite
> > > better and also think that the current 2.x version with all the
> > > advantages and disadvantages is far from exhausted its capabilities.
> > > I'm pretty sure the same motivation page exists for 3.0 version
> > > describing the advantages and disadvantages of developing mentioned
> > > IEPs. It will be good to share it prior to the cal also.
> > >
> > >
> > > [1]
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process#IEP69:Theevolutionaryreleaseprocess-Motivation
> > >
> > > On Thu, 11 Mar 2021 at 01:21, Valentin Kulichenko
> > > <va...@gmail.com> wrote:
> > > >
> > > > Ksenya, thanks for scheduling this so quickly!
> > > >
> > > > Guys, I hope we can make this discussion constructive. Please keep in
> > > mind
> > > > that Ignite 3 is an ongoing project supported by multiple
> contributors,
> > > > committers, and PMC members. Neglecting 6+ months of effort and
> > > suggesting
> > > > that it's just "prototyping some cool features and nothing more" is
> > > really
> > > > bizarre, and, quite frankly, sounds disrespectful to fellow
> developers
> > > > (although I'm 100% sure it was not intended this way).
> > > >
> > > > Maxim, one of the biggest issues I have with your IEP is that I don't
> > > > understand the motivation behind it. If you don't mind, I would like
> to
> > > > suggest that you kick off the meeting with a detailed explanation
> > > > of exactly that. The first step is to achieve a mutual understanding
> of
> > > > each other's goals. Once we do that, I'm sure we will easily find a
> > > > solution.
> > > >
> > > > -Val
> > > >
> > > > On Wed, Mar 10, 2021 at 8:55 AM Kseniya Romanova <
> > > romanova.ks.spb@gmail.com>
> > > > wrote:
> > > >
> > > > > Let's make a quick call next week and try to find a compromise
> which
> > > can
> > > > > get the process moving:
> > > > >
> https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/276851588/
> > > > >
> > > > > ср, 10 мар. 2021 г. в 16:27, Maxim Muzafarov <mm...@apache.org>:
> > > > >
> > > > > > Folks,
> > > > > >
> > > > > >
> > > > > > Agree, the discussion may be endless without compromises on all
> > > sides.
> > > > > > I always think that if there is no consensus (and I see from the
> > > > > > thread [1] that it's was no found) for such important decisions
> like
> > > > > > product future development and releases AFS provides the voting
> > > > > > procedure. Without fixing the results of the discussion [1] it
> sounds
> > > > > > like prototyping some cool features and nothing more.
> > > > > >
> > > > > > So, back to Denis suggestion can you share - what would be the
> best
> > > > > > time for all of us (considering different time zones) to have a
> call?
> > > > > >
> > > > > > I also think that we should start a vote about the future
> releases on
> > > > > > our Apache Ignite web-site and user-list, thus all who are using
> the
> > > > > > Apache Ignite may choose the best option they like.
> > > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> > > > > >
> > > > > > On Wed, 10 Mar 2021 at 03:57, Valentin Kulichenko
> > > > > > <va...@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Maxim,
> > > > > > >
> > > > > > > I disagree with the suggestions. Several community members have
> > > already
> > > > > > > pointed out the discussion about Ignite 3.0 [1]. During that
> > > > > discussion,
> > > > > > we
> > > > > > > did agree on the scope of the changes for 3.0, as well as the
> > > general
> > > > > > > direction for the product. The new repo was created not to
> "develop
> > > > > from
> > > > > > > scratch", but to provide an opportunity for the community
> members
> > > to
> > > > > > > actively work on Ignite 3 without killing the Ignite 2.x. No
> > > > > alternative
> > > > > > > solution for this was presented, so we went ahead with the
> process
> > > -- I
> > > > > > > consider that to be an example of the silent consensus.
> > > > > > >
> > > > > > > I also want to emphasize that Ignite 3 is active and is moving
> > > forward.
> > > > > > If
> > > > > > > you look at the ignite-3 repo, commits and PRs are coming in on
> > > regular
> > > > > > > basis. We also had the first alpha release early in the year.
> I do
> > > > > agree
> > > > > > > with you, however, that there is not too much activity on the
> dev
> > > list.
> > > > > > As
> > > > > > > far as I can tell, the main reason for this is that
> communication
> > > moved
> > > > > > to
> > > > > > > IEPs and GitHub PRs, for better or worse. This is something we
> all
> > > can
> > > > > > talk
> > > > > > > about -- I personally would like to see more discussions on
> the dev
> > > > > list.
> > > > > > >
> > > > > > > And finally, I agree with Denis. This whole situation is
> > > > > > > counter-productive. I'm happy to jump on a Discord or any other
> > > voice
> > > > > > chat
> > > > > > > to discuss in more detail.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > >
> > > > >
> > >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > > > On Fri, Mar 5, 2021 at 11:09 AM Maxim Muzafarov <
> mmuzaf@apache.org
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > 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
> > > > > > > >
> > > > > >
> > > > >
> > >
>

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Maxim Muzafarov <mm...@apache.org>.
Folks,


Thanks to everyone for participating in the call. Here is the list of
points we've agreed on and the list of actions which should be
discussed in more details.


= AGREED =

== Versioning ==

grand.major.bugfix[-rc_number]

The 'grand' version is fixed while both Ignite architectures (current
version 2.x and 3.x) are in a state of active development/maintained
or until otherwise is discussed further. This means:
- the master branch of the ignite repository [2] always release under
the '2.x.x' version
- the main branch of the ignite-3 repository [1] always release under
the '3.x.x' version

The 'major' versions for each architecture may contain breaking
backwards compatibility changes compared to the previous one if the
following criteria are met:
- users should be warned about breaking release changes (the ways of
notification should be additionally discussed and agreed upon)
- the deprecation rules may be applied for the current 'major' release
(the ways of deprecation must be additionally discussed and agreed
upon)
- current @deprecated already have enough time live and some of them
can be removed using common sense

The 'bugfix' version is used for emergency releases and can't contain
any breaking backwards compatibility changes.

== Commitments ==

Any commitment to support previous releases (e.g. 1 year, 1 quarter)
have no sense to the open-source Ignite community in the case of
observed backward compatibility violations, however, in any of such
cases, an emergency release can be performed according to the accepted
release procedure.


= DISCUSSION & SUGGESTIONS =


== Deprecation rules ==

The API deprecation rules must be discussed and agreed upon in more
details. The list of options we have:
- deprecate and remove API allowed in the next release
- deprecate and remove API allowed through the one release
- deprecation may contain comments - the release version then the API
will be changed
- deprecation may contain comments - the date from which the API changes allowed

I've checked the `JEP 277 Enhanced Deprecation` [3] proposal which
adds the `forRemoval` and `since` optional elements to the deprecated
annotation and I think we can use a similar approach here with some
additions. For instance, if the last released version is 2.10 my
suggestions would be the following:
- [case: change API as quickly as possible] mark some API as
deprecated, set 'since' version 2.12, change it in the 2.12 release
major version.
- [case: deprecate API without intention to change] mark API as
deprecated without 'since' options, change it without notifications
since 2.13 releases and so on.


== User notification rules ==

Uses must be well-notified about the planned backward compatibility
violations. The options we have:
- the notification thought the source code with well-described JavaDocs
- add labels to the JIRA issue if some deprecations occur in the related patch
- add deprecation and backward compatibility paragraph to the RELEASE_NOTES
- add a page to the Apache Ignite website with a backwards
compatibility description between the closest versions

All of the above must be done.


== Experimental and unstable APIs ==

The options we have:
- only the new API can be marked as unstable and/or experimental
- such APIs can be changed without any notifications


Please, share your thoughts.


[1] https://github.com/apache/ignite-3
[2] https://github.com/apache/ignite
[3] https://openjdk.java.net/jeps/277

On Mon, 15 Mar 2021 at 19:41, Dmitriy Pavlov <dp...@apache.org> wrote:
>
> Folks,
>
> let me add my 50 cents. I don't see major issues with this IEP, for now.
> And I really looking forward to talking about it. I can't get what causes
> misunderstanding.
>
> The only thing that concerns me here is that IEP requires the community to
> support solutions for 1 year, 1 quarter, etc.
>
> Apache community is not a commercial company that provides support of any
> kind, and I would be reluctant to add these or similar statements to any
> public documents. At any point in time, the community and PMC can vote and
> introduce any major feature breaking compatibility. We tend to avoid such
> actions to keep users best interest. But it is not a commitment.
>
> Sincerely
>
>
> чт, 11 мар. 2021 г. в 23:11, Maxim Muzafarov <mm...@apache.org>:
>
> > Val,
> >
> >
> > I'm sorry if anything from what I've said sounded disrespectful. All
> > of you are examples for me to follow :-)
> >
> > Have you checked the `motivation` [1] topic on the IEP-69 page? Should
> > I add more details to it prior to the call? I want to make Ignite
> > better and also think that the current 2.x version with all the
> > advantages and disadvantages is far from exhausted its capabilities.
> > I'm pretty sure the same motivation page exists for 3.0 version
> > describing the advantages and disadvantages of developing mentioned
> > IEPs. It will be good to share it prior to the cal also.
> >
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process#IEP69:Theevolutionaryreleaseprocess-Motivation
> >
> > On Thu, 11 Mar 2021 at 01:21, Valentin Kulichenko
> > <va...@gmail.com> wrote:
> > >
> > > Ksenya, thanks for scheduling this so quickly!
> > >
> > > Guys, I hope we can make this discussion constructive. Please keep in
> > mind
> > > that Ignite 3 is an ongoing project supported by multiple contributors,
> > > committers, and PMC members. Neglecting 6+ months of effort and
> > suggesting
> > > that it's just "prototyping some cool features and nothing more" is
> > really
> > > bizarre, and, quite frankly, sounds disrespectful to fellow developers
> > > (although I'm 100% sure it was not intended this way).
> > >
> > > Maxim, one of the biggest issues I have with your IEP is that I don't
> > > understand the motivation behind it. If you don't mind, I would like to
> > > suggest that you kick off the meeting with a detailed explanation
> > > of exactly that. The first step is to achieve a mutual understanding of
> > > each other's goals. Once we do that, I'm sure we will easily find a
> > > solution.
> > >
> > > -Val
> > >
> > > On Wed, Mar 10, 2021 at 8:55 AM Kseniya Romanova <
> > romanova.ks.spb@gmail.com>
> > > wrote:
> > >
> > > > Let's make a quick call next week and try to find a compromise which
> > can
> > > > get the process moving:
> > > > https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/276851588/
> > > >
> > > > ср, 10 мар. 2021 г. в 16:27, Maxim Muzafarov <mm...@apache.org>:
> > > >
> > > > > Folks,
> > > > >
> > > > >
> > > > > Agree, the discussion may be endless without compromises on all
> > sides.
> > > > > I always think that if there is no consensus (and I see from the
> > > > > thread [1] that it's was no found) for such important decisions like
> > > > > product future development and releases AFS provides the voting
> > > > > procedure. Without fixing the results of the discussion [1] it sounds
> > > > > like prototyping some cool features and nothing more.
> > > > >
> > > > > So, back to Denis suggestion can you share - what would be the best
> > > > > time for all of us (considering different time zones) to have a call?
> > > > >
> > > > > I also think that we should start a vote about the future releases on
> > > > > our Apache Ignite web-site and user-list, thus all who are using the
> > > > > Apache Ignite may choose the best option they like.
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> > > > >
> > > > > On Wed, 10 Mar 2021 at 03:57, Valentin Kulichenko
> > > > > <va...@gmail.com> wrote:
> > > > > >
> > > > > > Hi Maxim,
> > > > > >
> > > > > > I disagree with the suggestions. Several community members have
> > already
> > > > > > pointed out the discussion about Ignite 3.0 [1]. During that
> > > > discussion,
> > > > > we
> > > > > > did agree on the scope of the changes for 3.0, as well as the
> > general
> > > > > > direction for the product. The new repo was created not to "develop
> > > > from
> > > > > > scratch", but to provide an opportunity for the community members
> > to
> > > > > > actively work on Ignite 3 without killing the Ignite 2.x. No
> > > > alternative
> > > > > > solution for this was presented, so we went ahead with the process
> > -- I
> > > > > > consider that to be an example of the silent consensus.
> > > > > >
> > > > > > I also want to emphasize that Ignite 3 is active and is moving
> > forward.
> > > > > If
> > > > > > you look at the ignite-3 repo, commits and PRs are coming in on
> > regular
> > > > > > basis. We also had the first alpha release early in the year. I do
> > > > agree
> > > > > > with you, however, that there is not too much activity on the dev
> > list.
> > > > > As
> > > > > > far as I can tell, the main reason for this is that communication
> > moved
> > > > > to
> > > > > > IEPs and GitHub PRs, for better or worse. This is something we all
> > can
> > > > > talk
> > > > > > about -- I personally would like to see more discussions on the dev
> > > > list.
> > > > > >
> > > > > > And finally, I agree with Denis. This whole situation is
> > > > > > counter-productive. I'm happy to jump on a Discord or any other
> > voice
> > > > > chat
> > > > > > to discuss in more detail.
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Fri, Mar 5, 2021 at 11:09 AM Maxim Muzafarov <mmuzaf@apache.org
> > >
> > > > > wrote:
> > > > > >
> > > > > > > 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
> > > > > > >
> > > > >
> > > >
> >

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Dmitriy Pavlov <dp...@apache.org>.
Folks,

let me add my 50 cents. I don't see major issues with this IEP, for now.
And I really looking forward to talking about it. I can't get what causes
misunderstanding.

The only thing that concerns me here is that IEP requires the community to
support solutions for 1 year, 1 quarter, etc.

Apache community is not a commercial company that provides support of any
kind, and I would be reluctant to add these or similar statements to any
public documents. At any point in time, the community and PMC can vote and
introduce any major feature breaking compatibility. We tend to avoid such
actions to keep users best interest. But it is not a commitment.

Sincerely


чт, 11 мар. 2021 г. в 23:11, Maxim Muzafarov <mm...@apache.org>:

> Val,
>
>
> I'm sorry if anything from what I've said sounded disrespectful. All
> of you are examples for me to follow :-)
>
> Have you checked the `motivation` [1] topic on the IEP-69 page? Should
> I add more details to it prior to the call? I want to make Ignite
> better and also think that the current 2.x version with all the
> advantages and disadvantages is far from exhausted its capabilities.
> I'm pretty sure the same motivation page exists for 3.0 version
> describing the advantages and disadvantages of developing mentioned
> IEPs. It will be good to share it prior to the cal also.
>
>
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process#IEP69:Theevolutionaryreleaseprocess-Motivation
>
> On Thu, 11 Mar 2021 at 01:21, Valentin Kulichenko
> <va...@gmail.com> wrote:
> >
> > Ksenya, thanks for scheduling this so quickly!
> >
> > Guys, I hope we can make this discussion constructive. Please keep in
> mind
> > that Ignite 3 is an ongoing project supported by multiple contributors,
> > committers, and PMC members. Neglecting 6+ months of effort and
> suggesting
> > that it's just "prototyping some cool features and nothing more" is
> really
> > bizarre, and, quite frankly, sounds disrespectful to fellow developers
> > (although I'm 100% sure it was not intended this way).
> >
> > Maxim, one of the biggest issues I have with your IEP is that I don't
> > understand the motivation behind it. If you don't mind, I would like to
> > suggest that you kick off the meeting with a detailed explanation
> > of exactly that. The first step is to achieve a mutual understanding of
> > each other's goals. Once we do that, I'm sure we will easily find a
> > solution.
> >
> > -Val
> >
> > On Wed, Mar 10, 2021 at 8:55 AM Kseniya Romanova <
> romanova.ks.spb@gmail.com>
> > wrote:
> >
> > > Let's make a quick call next week and try to find a compromise which
> can
> > > get the process moving:
> > > https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/276851588/
> > >
> > > ср, 10 мар. 2021 г. в 16:27, Maxim Muzafarov <mm...@apache.org>:
> > >
> > > > Folks,
> > > >
> > > >
> > > > Agree, the discussion may be endless without compromises on all
> sides.
> > > > I always think that if there is no consensus (and I see from the
> > > > thread [1] that it's was no found) for such important decisions like
> > > > product future development and releases AFS provides the voting
> > > > procedure. Without fixing the results of the discussion [1] it sounds
> > > > like prototyping some cool features and nothing more.
> > > >
> > > > So, back to Denis suggestion can you share - what would be the best
> > > > time for all of us (considering different time zones) to have a call?
> > > >
> > > > I also think that we should start a vote about the future releases on
> > > > our Apache Ignite web-site and user-list, thus all who are using the
> > > > Apache Ignite may choose the best option they like.
> > > >
> > > >
> > > > [1]
> > > >
> > >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> > > >
> > > > On Wed, 10 Mar 2021 at 03:57, Valentin Kulichenko
> > > > <va...@gmail.com> wrote:
> > > > >
> > > > > Hi Maxim,
> > > > >
> > > > > I disagree with the suggestions. Several community members have
> already
> > > > > pointed out the discussion about Ignite 3.0 [1]. During that
> > > discussion,
> > > > we
> > > > > did agree on the scope of the changes for 3.0, as well as the
> general
> > > > > direction for the product. The new repo was created not to "develop
> > > from
> > > > > scratch", but to provide an opportunity for the community members
> to
> > > > > actively work on Ignite 3 without killing the Ignite 2.x. No
> > > alternative
> > > > > solution for this was presented, so we went ahead with the process
> -- I
> > > > > consider that to be an example of the silent consensus.
> > > > >
> > > > > I also want to emphasize that Ignite 3 is active and is moving
> forward.
> > > > If
> > > > > you look at the ignite-3 repo, commits and PRs are coming in on
> regular
> > > > > basis. We also had the first alpha release early in the year. I do
> > > agree
> > > > > with you, however, that there is not too much activity on the dev
> list.
> > > > As
> > > > > far as I can tell, the main reason for this is that communication
> moved
> > > > to
> > > > > IEPs and GitHub PRs, for better or worse. This is something we all
> can
> > > > talk
> > > > > about -- I personally would like to see more discussions on the dev
> > > list.
> > > > >
> > > > > And finally, I agree with Denis. This whole situation is
> > > > > counter-productive. I'm happy to jump on a Discord or any other
> voice
> > > > chat
> > > > > to discuss in more detail.
> > > > >
> > > > > [1]
> > > > >
> > > >
> > >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> > > > >
> > > > > -Val
> > > > >
> > > > > On Fri, Mar 5, 2021 at 11:09 AM Maxim Muzafarov <mmuzaf@apache.org
> >
> > > > wrote:
> > > > >
> > > > > > 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
> > > > > >
> > > >
> > >
>

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Maxim Muzafarov <mm...@apache.org>.
Val,


I'm sorry if anything from what I've said sounded disrespectful. All
of you are examples for me to follow :-)

Have you checked the `motivation` [1] topic on the IEP-69 page? Should
I add more details to it prior to the call? I want to make Ignite
better and also think that the current 2.x version with all the
advantages and disadvantages is far from exhausted its capabilities.
I'm pretty sure the same motivation page exists for 3.0 version
describing the advantages and disadvantages of developing mentioned
IEPs. It will be good to share it prior to the cal also.


[1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process#IEP69:Theevolutionaryreleaseprocess-Motivation

On Thu, 11 Mar 2021 at 01:21, Valentin Kulichenko
<va...@gmail.com> wrote:
>
> Ksenya, thanks for scheduling this so quickly!
>
> Guys, I hope we can make this discussion constructive. Please keep in mind
> that Ignite 3 is an ongoing project supported by multiple contributors,
> committers, and PMC members. Neglecting 6+ months of effort and suggesting
> that it's just "prototyping some cool features and nothing more" is really
> bizarre, and, quite frankly, sounds disrespectful to fellow developers
> (although I'm 100% sure it was not intended this way).
>
> Maxim, one of the biggest issues I have with your IEP is that I don't
> understand the motivation behind it. If you don't mind, I would like to
> suggest that you kick off the meeting with a detailed explanation
> of exactly that. The first step is to achieve a mutual understanding of
> each other's goals. Once we do that, I'm sure we will easily find a
> solution.
>
> -Val
>
> On Wed, Mar 10, 2021 at 8:55 AM Kseniya Romanova <ro...@gmail.com>
> wrote:
>
> > Let's make a quick call next week and try to find a compromise which can
> > get the process moving:
> > https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/276851588/
> >
> > ср, 10 мар. 2021 г. в 16:27, Maxim Muzafarov <mm...@apache.org>:
> >
> > > Folks,
> > >
> > >
> > > Agree, the discussion may be endless without compromises on all sides.
> > > I always think that if there is no consensus (and I see from the
> > > thread [1] that it's was no found) for such important decisions like
> > > product future development and releases AFS provides the voting
> > > procedure. Without fixing the results of the discussion [1] it sounds
> > > like prototyping some cool features and nothing more.
> > >
> > > So, back to Denis suggestion can you share - what would be the best
> > > time for all of us (considering different time zones) to have a call?
> > >
> > > I also think that we should start a vote about the future releases on
> > > our Apache Ignite web-site and user-list, thus all who are using the
> > > Apache Ignite may choose the best option they like.
> > >
> > >
> > > [1]
> > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> > >
> > > On Wed, 10 Mar 2021 at 03:57, Valentin Kulichenko
> > > <va...@gmail.com> wrote:
> > > >
> > > > Hi Maxim,
> > > >
> > > > I disagree with the suggestions. Several community members have already
> > > > pointed out the discussion about Ignite 3.0 [1]. During that
> > discussion,
> > > we
> > > > did agree on the scope of the changes for 3.0, as well as the general
> > > > direction for the product. The new repo was created not to "develop
> > from
> > > > scratch", but to provide an opportunity for the community members to
> > > > actively work on Ignite 3 without killing the Ignite 2.x. No
> > alternative
> > > > solution for this was presented, so we went ahead with the process -- I
> > > > consider that to be an example of the silent consensus.
> > > >
> > > > I also want to emphasize that Ignite 3 is active and is moving forward.
> > > If
> > > > you look at the ignite-3 repo, commits and PRs are coming in on regular
> > > > basis. We also had the first alpha release early in the year. I do
> > agree
> > > > with you, however, that there is not too much activity on the dev list.
> > > As
> > > > far as I can tell, the main reason for this is that communication moved
> > > to
> > > > IEPs and GitHub PRs, for better or worse. This is something we all can
> > > talk
> > > > about -- I personally would like to see more discussions on the dev
> > list.
> > > >
> > > > And finally, I agree with Denis. This whole situation is
> > > > counter-productive. I'm happy to jump on a Discord or any other voice
> > > chat
> > > > to discuss in more detail.
> > > >
> > > > [1]
> > > >
> > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> > > >
> > > > -Val
> > > >
> > > > On Fri, Mar 5, 2021 at 11:09 AM Maxim Muzafarov <mm...@apache.org>
> > > wrote:
> > > >
> > > > > 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
> > > > >
> > >
> >

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Valentin Kulichenko <va...@gmail.com>.
Ksenya, thanks for scheduling this so quickly!

Guys, I hope we can make this discussion constructive. Please keep in mind
that Ignite 3 is an ongoing project supported by multiple contributors,
committers, and PMC members. Neglecting 6+ months of effort and suggesting
that it's just "prototyping some cool features and nothing more" is really
bizarre, and, quite frankly, sounds disrespectful to fellow developers
(although I'm 100% sure it was not intended this way).

Maxim, one of the biggest issues I have with your IEP is that I don't
understand the motivation behind it. If you don't mind, I would like to
suggest that you kick off the meeting with a detailed explanation
of exactly that. The first step is to achieve a mutual understanding of
each other's goals. Once we do that, I'm sure we will easily find a
solution.

-Val

On Wed, Mar 10, 2021 at 8:55 AM Kseniya Romanova <ro...@gmail.com>
wrote:

> Let's make a quick call next week and try to find a compromise which can
> get the process moving:
> https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/276851588/
>
> ср, 10 мар. 2021 г. в 16:27, Maxim Muzafarov <mm...@apache.org>:
>
> > Folks,
> >
> >
> > Agree, the discussion may be endless without compromises on all sides.
> > I always think that if there is no consensus (and I see from the
> > thread [1] that it's was no found) for such important decisions like
> > product future development and releases AFS provides the voting
> > procedure. Without fixing the results of the discussion [1] it sounds
> > like prototyping some cool features and nothing more.
> >
> > So, back to Denis suggestion can you share - what would be the best
> > time for all of us (considering different time zones) to have a call?
> >
> > I also think that we should start a vote about the future releases on
> > our Apache Ignite web-site and user-list, thus all who are using the
> > Apache Ignite may choose the best option they like.
> >
> >
> > [1]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> >
> > On Wed, 10 Mar 2021 at 03:57, Valentin Kulichenko
> > <va...@gmail.com> wrote:
> > >
> > > Hi Maxim,
> > >
> > > I disagree with the suggestions. Several community members have already
> > > pointed out the discussion about Ignite 3.0 [1]. During that
> discussion,
> > we
> > > did agree on the scope of the changes for 3.0, as well as the general
> > > direction for the product. The new repo was created not to "develop
> from
> > > scratch", but to provide an opportunity for the community members to
> > > actively work on Ignite 3 without killing the Ignite 2.x. No
> alternative
> > > solution for this was presented, so we went ahead with the process -- I
> > > consider that to be an example of the silent consensus.
> > >
> > > I also want to emphasize that Ignite 3 is active and is moving forward.
> > If
> > > you look at the ignite-3 repo, commits and PRs are coming in on regular
> > > basis. We also had the first alpha release early in the year. I do
> agree
> > > with you, however, that there is not too much activity on the dev list.
> > As
> > > far as I can tell, the main reason for this is that communication moved
> > to
> > > IEPs and GitHub PRs, for better or worse. This is something we all can
> > talk
> > > about -- I personally would like to see more discussions on the dev
> list.
> > >
> > > And finally, I agree with Denis. This whole situation is
> > > counter-productive. I'm happy to jump on a Discord or any other voice
> > chat
> > > to discuss in more detail.
> > >
> > > [1]
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> > >
> > > -Val
> > >
> > > On Fri, Mar 5, 2021 at 11:09 AM Maxim Muzafarov <mm...@apache.org>
> > wrote:
> > >
> > > > 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
> > > >
> >
>

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Kseniya Romanova <ro...@gmail.com>.
Let's make a quick call next week and try to find a compromise which can
get the process moving:
https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/276851588/

ср, 10 мар. 2021 г. в 16:27, Maxim Muzafarov <mm...@apache.org>:

> Folks,
>
>
> Agree, the discussion may be endless without compromises on all sides.
> I always think that if there is no consensus (and I see from the
> thread [1] that it's was no found) for such important decisions like
> product future development and releases AFS provides the voting
> procedure. Without fixing the results of the discussion [1] it sounds
> like prototyping some cool features and nothing more.
>
> So, back to Denis suggestion can you share - what would be the best
> time for all of us (considering different time zones) to have a call?
>
> I also think that we should start a vote about the future releases on
> our Apache Ignite web-site and user-list, thus all who are using the
> Apache Ignite may choose the best option they like.
>
>
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
>
> On Wed, 10 Mar 2021 at 03:57, Valentin Kulichenko
> <va...@gmail.com> wrote:
> >
> > Hi Maxim,
> >
> > I disagree with the suggestions. Several community members have already
> > pointed out the discussion about Ignite 3.0 [1]. During that discussion,
> we
> > did agree on the scope of the changes for 3.0, as well as the general
> > direction for the product. The new repo was created not to "develop from
> > scratch", but to provide an opportunity for the community members to
> > actively work on Ignite 3 without killing the Ignite 2.x. No alternative
> > solution for this was presented, so we went ahead with the process -- I
> > consider that to be an example of the silent consensus.
> >
> > I also want to emphasize that Ignite 3 is active and is moving forward.
> If
> > you look at the ignite-3 repo, commits and PRs are coming in on regular
> > basis. We also had the first alpha release early in the year. I do agree
> > with you, however, that there is not too much activity on the dev list.
> As
> > far as I can tell, the main reason for this is that communication moved
> to
> > IEPs and GitHub PRs, for better or worse. This is something we all can
> talk
> > about -- I personally would like to see more discussions on the dev list.
> >
> > And finally, I agree with Denis. This whole situation is
> > counter-productive. I'm happy to jump on a Discord or any other voice
> chat
> > to discuss in more detail.
> >
> > [1]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> >
> > -Val
> >
> > On Fri, Mar 5, 2021 at 11:09 AM Maxim Muzafarov <mm...@apache.org>
> wrote:
> >
> > > 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
> > >
>

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Maxim Muzafarov <mm...@apache.org>.
Folks,


Agree, the discussion may be endless without compromises on all sides.
I always think that if there is no consensus (and I see from the
thread [1] that it's was no found) for such important decisions like
product future development and releases AFS provides the voting
procedure. Without fixing the results of the discussion [1] it sounds
like prototyping some cool features and nothing more.

So, back to Denis suggestion can you share - what would be the best
time for all of us (considering different time zones) to have a call?

I also think that we should start a vote about the future releases on
our Apache Ignite web-site and user-list, thus all who are using the
Apache Ignite may choose the best option they like.


[1] http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html

On Wed, 10 Mar 2021 at 03:57, Valentin Kulichenko
<va...@gmail.com> wrote:
>
> Hi Maxim,
>
> I disagree with the suggestions. Several community members have already
> pointed out the discussion about Ignite 3.0 [1]. During that discussion, we
> did agree on the scope of the changes for 3.0, as well as the general
> direction for the product. The new repo was created not to "develop from
> scratch", but to provide an opportunity for the community members to
> actively work on Ignite 3 without killing the Ignite 2.x. No alternative
> solution for this was presented, so we went ahead with the process -- I
> consider that to be an example of the silent consensus.
>
> I also want to emphasize that Ignite 3 is active and is moving forward. If
> you look at the ignite-3 repo, commits and PRs are coming in on regular
> basis. We also had the first alpha release early in the year. I do agree
> with you, however, that there is not too much activity on the dev list. As
> far as I can tell, the main reason for this is that communication moved to
> IEPs and GitHub PRs, for better or worse. This is something we all can talk
> about -- I personally would like to see more discussions on the dev list.
>
> And finally, I agree with Denis. This whole situation is
> counter-productive. I'm happy to jump on a Discord or any other voice chat
> to discuss in more detail.
>
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
>
> -Val
>
> On Fri, Mar 5, 2021 at 11:09 AM Maxim Muzafarov <mm...@apache.org> wrote:
>
> > 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
> >

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Valentin Kulichenko <va...@gmail.com>.
Hi Maxim,

I disagree with the suggestions. Several community members have already
pointed out the discussion about Ignite 3.0 [1]. During that discussion, we
did agree on the scope of the changes for 3.0, as well as the general
direction for the product. The new repo was created not to "develop from
scratch", but to provide an opportunity for the community members to
actively work on Ignite 3 without killing the Ignite 2.x. No alternative
solution for this was presented, so we went ahead with the process -- I
consider that to be an example of the silent consensus.

I also want to emphasize that Ignite 3 is active and is moving forward. If
you look at the ignite-3 repo, commits and PRs are coming in on regular
basis. We also had the first alpha release early in the year. I do agree
with you, however, that there is not too much activity on the dev list. As
far as I can tell, the main reason for this is that communication moved to
IEPs and GitHub PRs, for better or worse. This is something we all can talk
about -- I personally would like to see more discussions on the dev list.

And finally, I agree with Denis. This whole situation is
counter-productive. I'm happy to jump on a Discord or any other voice chat
to discuss in more detail.

[1]
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html

-Val

On Fri, Mar 5, 2021 at 11:09 AM Maxim Muzafarov <mm...@apache.org> wrote:

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

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Nikolay Izhikov <ni...@apache.org>.
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 <mm...@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
> <al...@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 <mm...@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 <pt...@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 <mm...@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 <mm...@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 <pt...@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.kasnacheev@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 <mm...@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

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Maxim Muzafarov <mm...@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
<al...@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 <mm...@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 <pt...@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 <mm...@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 <mm...@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 <pt...@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.kasnacheev@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 <mm...@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

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Alexei Scherbakov <al...@gmail.com>.
  -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 <mm...@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 <pt...@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 <mm...@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 <mm...@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 <pt...@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.kasnacheev@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 <mm...@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

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Maxim Muzafarov <mm...@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 <pt...@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 <mm...@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 <mm...@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 <pt...@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.kasnacheev@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 <mm...@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
> > > > > >
> > > > >
> >

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Pavel Tupitsyn <pt...@apache.org>.
-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 <mm...@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 <mm...@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 <pt...@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.kasnacheev@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 <mm...@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
> > > > >
> > > >
>

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Maxim Muzafarov <mm...@apache.org>.
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 <mm...@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 <pt...@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 <il...@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 <mm...@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
> > > >
> > >

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Maxim Muzafarov <mm...@apache.org>.
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 <pt...@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 <il...@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 <mm...@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
> > >
> >

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <il...@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 <mm...@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
> >
>

Re: [DISCUSSION] IEP-69 The evolutionary release process

Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <mm...@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
>