[jira] [Created] (IGNITE-14290) Implement Schema desciptor.

[Andrey Mashenkov (Jira)]

Andrey Mashenkov created IGNITE-14290:
-

 Summary: Implement Schema desciptor.
 Key: IGNITE-14290
 URL: https://issues.apache.org/jira/browse/IGNITE-14290
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Mashenkov


Implement schema configuration API from IGNITE-13748 and internal 
SchemaDescriptor.
Native types implementations are suggested in IGNITE-13617.





--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[Pavel Tupitsyn]

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

> Hello, Maxim.
>
> I’m +1 to follow your proposal.
>
> > 5 марта 2021 г., в 22:08, Maxim Muzafarov 
> написал(а):
> >
> > 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
>
>

[jira] [Created] (IGNITE-14291) Implement user class mappers.

[Andrey Mashenkov (Jira)]

Andrey Mashenkov created IGNITE-14291:
-

 Summary: Implement user class mappers.
 Key: IGNITE-14291
 URL: https://issues.apache.org/jira/browse/IGNITE-14291
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Mashenkov


Implement user-class mappers for key-value view and record view and add custom 
mapper support to marshallers initially implemented in IGNITE-13618.

Supposed, mappers are used for schema generation from user-classes (annotation 
schema configuration) and schema validation.
Mappers might be highly coupled with marshallers\serislizers (especially 
generated marshaller).




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Apache Ignite 3.x: order in repository

[Yakov]

>For example, by enforcing that all changes are
merged only through PRs. That, however, means that all contributors are
forced to work with GitHub, which is not necessarily a great thing.


I think we had this flow in mind when Ignite was started. I don't see any
issue with forking unless prs can be integrated to the process, e.g. tc
visas, jira, etc.

Agree with Pavel - PRs older than some threshold can be closed. As far as
Stephen's comment for PRs being ignored I would say that it is more on
author of the PR to drive the PR to the point it gets merged by seeking the
review(ers) and making sure all the checks pass. And any closed PR can be
brought back

Yakov

On Thu, Mar 4, 2021, 05:19 Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Petr,
>
> Any suggestions on how to fix this? One of the ideas that come to my mind
> is to unify the process. For example, by enforcing that all changes are
> merged only through PRs. That, however, means that all contributors are
> forced to work with GitHub, which is not necessarily a great thing.
>
> Thoughts?
>
> -Val
>
> On Wed, Feb 24, 2021 at 12:45 AM Petr Ivanov  wrote:
>
> > I'd guess that one of the main problem with inactive PRs is in creation
> of
> > PR for reviewing but merging it from command line (not via GitHub
> > interface).
> > Also, of course, there are lots of efforts which are abandoned after
> first
> > review, or even do not have a chance to be reviewed at all.
> >
> >
> > > On 22 Feb 2021, at 11:51, Stephen Darlington <
> > stephen.darling...@gridgain.com> wrote:
> > >
> > > I think we need to be able answer the question “Why are there so many
> > inactive PRs?" before we automate their removal. If perfectly good
> changes
> > are being ignored, we have a problem.
> > >
> > > Removing branches of merged PRs and protecting the main branch make
> > sense.
> > >
> > >> On 20 Feb 2021, at 18:30, Pavel Tupitsyn 
> wrote:
> > >>
> > >> +1
> > >>
> > >> - Close inactive PRs (1 month or so?)
> > >> - Enable main branch protection (no force pushes, require linear
> > history,
> > >> require status checks)
> > >>
> > >> On Sat, Feb 20, 2021 at 2:31 PM Petr Ivanov 
> > wrote:
> > >>
> > >>> Hi, Igniters!
> > >>>
> > >>>
> > >>> When we started Ignite 3.x in new repository, not only we have
> > received a
> > >>> chance to cleanup codebase, but to maintain some order in development
> > >>> tools, like GitHub.
> > >>> Currently in 2.x repository we have lots of stalled PRs and branches,
> > >>> which not only clog the repository, but also indirectly influence TC
> > >>> performance (due to necessity to check for updates every ref:
> branches
> > and
> > >>> PRs).
> > >>>
> > >>> Could I suggest we devise some recommendations for using PR's and
> > branches
> > >>> in new repo and add some rules about stalled PRs at least, like
> closing
> > >>> them if inactive for some time.
> > >>> Also we can activate some settings in repo's configuration, like auto
> > >>> delete branch after PR is merged.
> > >>>
> > >>>
> > >>> WDYT?
> > >
> > >
> >
> >
>

Re: IEP-68: Thin Client Data Streamer

[Pavel Tupitsyn]

Alex,

I did not include this for two reasons:

1) Existing thick API behavior is very confusing and counter-intuitive:
it returns a Future that won't complete unless you call more APIs.

I've seen multiple users doing this:
await streamer.Add(1, 1);
await streamer.Add(2, 2);

This code hangs - the first Add will never complete, because the batch is
not sent,
and the batch won't be sent because we are awaiting the first Add.

2) I'm not sure what's the use case for this feature - why do we want to
know
when the flush happens?

We can come up with a better API, but should we bother at all?

On Fri, Mar 5, 2021 at 6:09 PM Alex Plehanov 
wrote:

> Pavel,
>
> IEP looks good to me overall. I have only one concern: currently, for thick
> client "add" method we return the future which completes when the current
> batch is actually added to the cache, even if "flush" method is not invoked
> explicitly. For thin client with the proposed protocol we can't provide
> such functionality without explicit "flush". Perhaps we should notify
> client when batch actually flushed and send this notification when some
> "require notification" flag is sent with the request. WDYT?
>
> пт, 5 мар. 2021 г. в 17:03, Ivan Daschinsky :
>
> > Agree, this is completely offtopic here.
> >
> > пт, 5 мар. 2021 г. в 17:02, Pavel Tupitsyn :
> >
> > > > custom DSL
> > > This is a topic for 3.0 - would you like to start a separate thread?
> > >
> > > On Fri, Mar 5, 2021 at 4:54 PM Ivan Daschinsky 
> > > wrote:
> > >
> > > > I suppose, that the best variantl -- custom DSL similar to MongoDB
> > query
> > > > language.
> > > > I understand that implementing this is much harder, but users want
> this
> > > > variant.
> > > >
> > > > пт, 5 мар. 2021 г. в 16:52, Pavel Tupitsyn :
> > > >
> > > > > > I suppose this is of questional usability, same for existing
> > > > > > implementation for ScanQuery and ContinousQuery
> > > > >
> > > > > One way or another, we need to be able to run custom logic
> > > > > on the server side from thin clients.
> > > > >
> > > > > Our current direction can be seen as "Java is our DSL":
> > > > > write server-side logic in Java, deploy to servers, call from thin
> > > > clients.
> > > > >
> > > > > This approach is already used for Services, Compute, ScanQuery,
> > > > > ContinuousQuery.
> > > > >
> > > > > If you have a better idea in mind, please share.
> > > > >
> > > > > On Fri, Mar 5, 2021 at 4:12 PM Ivan Daschinsky <
> ivanda...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > >>> - Corresponding types should exist on server nodes
> > > > > > Ok, but I suppose this is of questional usability, same for
> > existing
> > > > > > implementation for ScanQuery and ContinousQuery.
> > > > > > For queries it's probably ok to add some custom filters and put
> > them
> > > in
> > > > > > servers' classpathes, but I can hardly imagine
> > > > > > somebody wants to create custom Receiver this way.
> > > > > >
> > > > > > пт, 5 мар. 2021 г. в 15:54, Pavel Tupitsyn  >:
> > > > > >
> > > > > > > > How do you suggests to serialize this object?
> > > > > > >
> > > > > > > Like a normal binary object. This scenario already exists for
> > > > ScanQuery
> > > > > > and
> > > > > > > ContinuousQuery filters.
> > > > > > > - It works for Java and .NET; potentially for other platforms
> > > > > > > - Corresponding types should exist on server nodes
> > > > > > >
> > > > > > > E.g. if a Java class `MyFilter { String containsText }` is
> loaded
> > > on
> > > > > > server
> > > > > > > nodes,
> > > > > > > a Python thin client can easily write a corresponding
> > BinaryObject
> > > > with
> > > > > > one
> > > > > > > field to achieve server-side filtering.
> > > > > > >
> > > > > > >
> > > > > > > > I also suppose, that closing should be done wia
> > OP_RESOURCE_CLOSE
> > > > > > >
> > > > > > > Thanks, forgot to mention this - updated the IEP.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Mar 5, 2021 at 3:42 PM Ivan Daschinsky <
> > > ivanda...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I also suppose, that closing should be done wia
> > > OP_RESOURCE_CLOSE.
> > > > > > It'is
> > > > > > > > more consistent and resembles with existing cursor api.
> > > > > > > >
> > > > > > > > пт, 5 мар. 2021 г. в 15:37, Ivan Daschinsky <
> > ivanda...@gmail.com
> > > >:
> > > > > > > >
> > > > > > > > > >> Both proposed requests have a Flush flag - please see
> > > Details
> > > > > > > sections
> > > > > > > > > in the IEP.
> > > > > > > > > Ok, sorry, I missed this.
> > > > > > > > > >> StreamReceiver is public API [1]
> > > > > > > > > I know it. But this "object" should contains custom logic
> for
> > > > > putting
> > > > > > > > data
> > > > > > > > > in cache. How do you suggests to serialize this object?
> > > > > > > > > Implement custom classloader for java? What about other
> > > > platforms?
> > > > > > > > >
> > > > > > > > > I suppose that we should not add this field, because it is
> > > > > confusing.
> > > > > 

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

[Maxim Muzafarov]

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  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  wrote:
>
> > Hello, Maxim.
> >
> > I’m +1 to follow your proposal.
> >
> > > 5 марта 2021 г., в 22:08, Maxim Muzafarov 
> > написал(а):
> > >
> > > 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
> >
> >

[jira] [Created] (IGNITE-14292) Change permissions required to create/destroy caches in GridRestProcessor

[Andrey Kuznetsov (Jira)]

Andrey Kuznetsov created IGNITE-14292:
-

 Summary: Change permissions required to create/destroy caches in 
GridRestProcessor
 Key: IGNITE-14292
 URL: https://issues.apache.org/jira/browse/IGNITE-14292
 Project: Ignite
  Issue Type: Improvement
  Components: security
Affects Versions: 2.9.1
Reporter: Andrey Kuznetsov


{{GridRestProcessor}} authorizes {{ADMIN_CACHE}} permission before cache 
creation/destruction. This is inconsistent with thin client connector behavior 
and looks counterintuitive. {{ADMIN_CACHE}} should be replaced with 
{{CACHE_CREATE}} and {{CACHE_DESTROY}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[Ilya Kasnacheev]

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 :

> 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: Minor PR

[Ilya Kasnacheev]

Hello!

You can use MTCGA to check those runs, such as
https://mtcga.gridgain.com/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/8845/head&action=Latest

This one looks OK, I will merge.

Regards,
-- 
Ilya Kasnacheev


пн, 8 мар. 2021 г. в 10:57, Atri Sharma :

> Hello,
>
> I ran the test suite and here is the link:
>
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5906237
>
> I ran all of the failed tests but they passed for me. Most of them are
> marked as flaky.
>
> Regards,
>
> Atri
>
> On Fri, Mar 5, 2021 at 5:42 PM Ilya Kasnacheev
>  wrote:
> >
> > Hello!
> >
> > Please run tests against this change, get a green TC visa for the ticket.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 3 мар. 2021 г. в 17:13, Atri Sharma :
> >
> > > Hi,
> > >
> > > Please help review this PR:
> > >
> > > https://github.com/apache/ignite/pull/8845
> > >
> > > Regards,
> > >
> > > Atri
> > >
>
> --
> Regards,
>
> Atri
> Apache Concerted
>

Re: Minor PR

[Atri Sharma]

Thank you!

On Tue, 9 Mar 2021, 21:46 Ilya Kasnacheev, 
wrote:

> Hello!
>
> You can use MTCGA to check those runs, such as
>
> https://mtcga.gridgain.com/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/8845/head&action=Latest
>
> This one looks OK, I will merge.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 8 мар. 2021 г. в 10:57, Atri Sharma :
>
> > Hello,
> >
> > I ran the test suite and here is the link:
> >
> >
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5906237
> >
> > I ran all of the failed tests but they passed for me. Most of them are
> > marked as flaky.
> >
> > Regards,
> >
> > Atri
> >
> > On Fri, Mar 5, 2021 at 5:42 PM Ilya Kasnacheev
> >  wrote:
> > >
> > > Hello!
> > >
> > > Please run tests against this change, get a green TC visa for the
> ticket.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > ср, 3 мар. 2021 г. в 17:13, Atri Sharma :
> > >
> > > > Hi,
> > > >
> > > > Please help review this PR:
> > > >
> > > > https://github.com/apache/ignite/pull/8845
> > > >
> > > > Regards,
> > > >
> > > > Atri
> > > >
> >
> > --
> > Regards,
> >
> > Atri
> > Apache Concerted
> >
>

[jira] [Created] (IGNITE-14293) .NET: AffinityKey does not work

[Pavel Tupitsyn (Jira)]

Pavel Tupitsyn created IGNITE-14293:
---

 Summary: .NET: AffinityKey does not work
 Key: IGNITE-14293
 URL: https://issues.apache.org/jira/browse/IGNITE-14293
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.10
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.10


{{AffinityKey}} does not work as expected - {{Affinity}} property is not used 
for affinity calculation.

This is caused by IGNITE-13160: {{AffinityKey}} system type is overwritten by 
{{UnmanagedCallbacks.BinaryTypeGet}} call. As a result, this type becomes a 
regular, user type, and does not map to a corresponding type on the Java side.

* Add test that combines QueryEntity with AffinityKey
* Check that other system types (IgniteUuid, etc) don't have this problem, add 
tests
* Make sure we never overwrite system types during registration
* Improve examples tests: Thick Sql example provides inconsistent output due to 
this bug




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: IGNITE-2399 : Asynchronous Acquire method in IgniteSemaphore

[Atri Sharma]

Gentle ping

On Mon, 8 Mar 2021, 13:51 Atri Sharma,  wrote:

> Hi All,
>
> I would like to start a discussion around IGNITE-2399.
>
> Background: The typical use of IgniteSemaphore consists of acquiring
> the semaphore, performing the task and releasing the semaphore. This
> JIRA proposes a new method which will accept a callable, acquire the
> semaphore, and return a future. Upon completion of the future, the
> semaphore is released.
>
> This API seems useful for an easy encapsulation of the described use
> case and does not cause an internal flux since all the changes are
> focused at the public API.
>
> WIP PR for the same:
>
> https://github.com/apache/ignite/pull/8820
>
> Please share your thoughts and comments.
>
> --
> Regards,
>
> Atri
> Apache Concerted
>

Re: [CANCEL] [VOTE] Release Apache Ignite 2.10.0 RC1

[Pavel Tupitsyn]

Can we include the fix for this as well? I'm working on it.
https://issues.apache.org/jira/browse/IGNITE-14293

On Mon, Mar 8, 2021 at 9:18 PM Maxim Muzafarov  wrote:

> Folks,
>
> The vote cancelled. The following issues need to be addressed:
> https://issues.apache.org/jira/browse/IGNITE-14284
> https://issues.apache.org/jira/browse/IGNITE-14285
>

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

[Pavel Tupitsyn]

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

[Maxim Muzafarov]

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

[Maxim Muzafarov]

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

[Pavel Tupitsyn]

-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  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  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 
> wrote:
> > >
> > > Maxim,
> > >
> > > What you propose is
> > >
> > > 1) Take Ignite 2.x, remove some deprecated features, and release that
> as
> > > Ignite 3.0
> > > 2) Much later, release what is being worked on in ignite-3 as Ignite
> 4.0 or
> > > 5.0
> > >
> > > Do I understand this correctly?
> > >
> > > On Tue, Mar 9, 2021 at 7:15 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > 0. I am accustomed with major.minor.maintenance schema. Does it make
> any
> > > > difference?
> > > > 2. What's `lock'?
> > > > 3. I don't see why there would be implicit PDS compatibility between
> any
> > > > X.0.0 and Y.0.0, X != Y.
> > > > 4. I think this is a sensible approach.
> > > > 5. Since ignite-3 seems to be a separate repo ATM, I don't see why
> it is
> > > > applicable.
> > > >
> > > > Regards,
> > > >
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > пт, 5 мар. 2021 г. в 22:09, Maxim Muzafarov :
> > > >
> > > > > 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

[Maxim Muzafarov]

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  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  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  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 
> > wrote:
> > > >
> > > > Maxim,
> > > >
> > > > What you propose is
> > > >
> > > > 1) Take Ignite 2.x, remove some deprecated features, and release that
> > as
> > > > Ignite 3.0
> > > > 2) Much later, release what is being worked on in ignite-3 as Ignite
> > 4.0 or
> > > > 5.0
> > > >
> > > > Do I understand this correctly?
> > > >
> > > > On Tue, Mar 9, 2021 at 7:15 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > 0. I am accustomed with major.minor.maintenance schema. Does it make
> > any
> > > > > difference?
> > > > > 2. What's `lock'?
> > > > > 3. I don't see why there would be implicit PDS compatibility between
> > any
> > > > > X.0.0 and Y.0.0, X != Y.
> > > > > 4. I think this is a sensible approach.
> > > > > 5. Since ignite-3 seems to be a separate repo ATM, I don't see why
> > it is
> > > > > applicable.
> > > > >
> > > > > Regards,
> > > > >
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > пт, 5 мар. 2021 г. в 22:09, Maxim Muzafarov :
> > > > >
> > > > > > 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.
> > > > > >
> >

Re: [CANCEL] [VOTE] Release Apache Ignite 2.10.0 RC1

[Maxim Muzafarov]

Pavel,

Sure, let's wait a couple of days for this fix too. Please, let me
know when it will be ready.
If it takes a long time to fix it I propose to release changes with
`set of known issues`.

On Tue, 9 Mar 2021 at 19:23, Pavel Tupitsyn  wrote:
>
> Can we include the fix for this as well? I'm working on it.
> https://issues.apache.org/jira/browse/IGNITE-14293
>
> On Mon, Mar 8, 2021 at 9:18 PM Maxim Muzafarov  wrote:
>
> > Folks,
> >
> > The vote cancelled. The following issues need to be addressed:
> > https://issues.apache.org/jira/browse/IGNITE-14284
> > https://issues.apache.org/jira/browse/IGNITE-14285
> >

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

[Alexei Scherbakov]

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

> 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  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 
> 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 
> 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 
> > > wrote:
> > > > >
> > > > > Maxim,
> > > > >
> > > > > What you propose is
> > > > >
> > > > > 1) Take Ignite 2.x, remove some deprecated features, and release
> that
> > > as
> > > > > Ignite 3.0
> > > > > 2) Much later, release what is being worked on in ignite-3 as
> Ignite
> > > 4.0 or
> > > > > 5.0
> > > > >
> > > > > Do I understand this correctly?
> > > > >
> > > > > On Tue, Mar 9, 2021 at 7:15 PM Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > 0. I am accustomed with major.minor.maintenance schema. Does it
> make
> > > any
> > > > > > difference?
> > > > > > 2. What's `lock'?
> > > > > > 3. I don't see why there would be implicit PDS compatibility
> between
> > > any
> > > > > > X.0.0 and Y.0.0, X != Y.
> > > > > > 4. I think this is a sensible approach.
> > > > > > 5. Since ignite-3 seems to be a separate repo ATM, I don't see
> why
> > > it is
> > > > > > applicable.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > пт, 5 мар. 2021 г. в 22:09, Maxim Muzafarov :
> > > > > >
> > > > > > > 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 thin

Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)

[Maxim Muzafarov]

Folks,


Sharing the release status:

.NET: AffinityKey does not work - In-Progress
https://issues.apache.org/jira/browse/IGNITE-14293

sqlline: `Property "url" is required' - Patch Available
https://issues.apache.org/jira/browse/IGNITE-14284

sqllline: `Bad history file syntax!' - Resolved
https://issues.apache.org/jira/browse/IGNITE-14285


I'd like to cherry-pick the following fixed bugs to the 2.10 release branch.
Do you have any objections?

IGNITE-14250 .NET: Fix race condition in Events example, test example output
https://issues.apache.org/jira/browse/IGNITE-14250

IGNITE-14168 fix description of validate_indexes command (#8798)
https://issues.apache.org/jira/browse/IGNITE-14168

IGNITE-14138 Fixed an issue where historical rebalance can kill
supplier node. Fixes #8769
https://issues.apache.org/jira/browse/IGNITE-14138

On Mon, 1 Mar 2021 at 21:26, Maxim Muzafarov  wrote:
>
> Igor,
>
> Many thanks for fixing the issue!
> I've cherry-picked it to the 2.10 branch.
>
> Folks,
>
> I'll finalize the latest changes for the documentation pages and
> prepare the rc build shortly.
>
> On Mon, 1 Mar 2021 at 21:08, Igor Sapego  wrote:
> >
> > The following commit should be cherry-picked: 
> > 0675e2a7e800730c9c8230332b82809754ddae5a
> >
> > Sorry for a delay.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Mar 1, 2021 at 9:06 PM Igor Sapego  wrote:
> >>
> >> Maxim,
> >>
> >> The issue is fixed and is merged to master now.
> >>
> >> Best Regards,
> >> Igor
> >>
> >>
> >> On Sun, Feb 28, 2021 at 8:12 PM Maxim Muzafarov  wrote:
> >>>
> >>> Hello Igor,
> >>>
> >>> >  I believe I could fix the ticket [1] by the end of the next week.
> >>> Should we still wait a bit for t his fix or postpone it to 2.10.1? WDYT?
> >>>
> >>>
> >>>
> >>> [1] https://issues.apache.org/jira/browse/IGNITE-14204
> >>>
> >>> On Fri, 26 Feb 2021 at 11:20, Max Timonin  wrote:
> >>> >
> >>> > Hi, Maxim!
> >>> >
> >>> > The bug IGNITE-14206 [1] fixed. There are 2 commits to cherry-pick
> >>> >
> >>> > 1.
> >>> > https://github.com/apache/ignite/commit/851f650ba03e0b6c081cfe23f411fd2bf6be0228
> >>> > 2.
> >>> > https://github.com/apache/ignite/commit/93b74922bd04b164301d7bc5a2788b9693d4a8a4
> >>> >
> >>> >
> >>> > https://issues.apache.org/jira/browse/IGNITE-14206
> >>> >
> >>> > On Wed, Feb 24, 2021 at 5:47 PM Maxim Muzafarov  
> >>> > wrote:
> >>> >
> >>> > > Anton,
> >>> > >
> >>> > > Your improvement is very important, for sure, but it's almost 2 months
> >>> > > have passed since the initiation of the release branch. I think we
> >>> > > should prepare the changes as fast as possible for now and initiate
> >>> > > with the next one release. In general, it would be nice to have a
> >>> > > release plan for the year ahead so each developer will understand on
> >>> > > which release his changes can get into.
> >>> > >
> >>> > > That's why I'm going to prepare an RC-build on Monday 1-st March.
> >>> > >
> >>> > > On Wed, 24 Feb 2021 at 11:13, Anton Vinogradov  
> >>> > > wrote:
> >>> > > >
> >>> > > > Maxim,
> >>> > > >
> >>> > > > https://issues.apache.org/jira/browse/IGNITE-13873
> >>> > > > Is ready for review, is it possible to wait for it?
> >>> > > >
> >>> > > > On Wed, Feb 24, 2021 at 12:01 AM Maxim Muzafarov 
> >>> > > wrote:
> >>> > > >
> >>> > > > > Folks,
> >>> > > > >
> >>> > > > >
> >>> > > > > I'd like to cherry-pick to the release branch the following fixes:
> >>> > > > >
> >>> > > > > Fix security context for JDBC bulk-load operations
> >>> > > > > https://issues.apache.org/jira/browse/IGNITE-13472
> >>> > > > >
> >>> > > > > Fixed an issue that caused a deadlock when user cache was created 
> >>> > > > > in
> >>> > > > > parallel with TTL worker was in progress.
> >>> > > > > https://issues.apache.org/jira/browse/IGNITE-14078
> >>> > > > >
> >>> > > > > On Thu, 18 Feb 2021 at 20:26, Maxim Muzafarov 
> >>> > > wrote:
> >>> > > > > >
> >>> > > > > > Maxim, Igor,
> >>> > > > > >
> >>> > > > > > Thanks for sharing details.
> >>> > > > > > Let's wait for these fixes.
> >>> > > > > >
> >>> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14206
> >>> > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-14204
> >>> > > > > >
> >>> > > > > > On Thu, 18 Feb 2021 at 18:35, Igor Sapego 
> >>> > > wrote:
> >>> > > > > > >
> >>> > > > > > > Maxim,
> >>> > > > > > >
> >>> > > > > > > I believe I could fix the ticket [1] by the end of the next 
> >>> > > > > > > week.
> >>> > > > > > >
> >>> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14204
> >>> > > > > > >
> >>> > > > > > > Best Regards,
> >>> > > > > > > Igor
> >>> > > > > > >
> >>> > > > > > >
> >>> > > > > > > On Thu, Feb 18, 2021 at 6:30 PM Max Timonin <
> >>> > > timonin.ma...@gmail.com>
> >>> > > > > wrote:
> >>> > > > > > >
> >>> > > > > > > > Hi! I've today found an issue [1], there is wrong handling 
> >>> > > > > > > > of
> >>> > > > > inlined POJO.
> >>> > > > > > > > This bug appeared in 2.9.0 and makes it impossible to work 
> >>> > > > > > >

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

[Maxim Muzafarov]

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

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

[Nikolay Izhikov]

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  написал(а):
> 
> 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
>  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 :
>> 
>>> 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  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 
>>> 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 
>>> 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:
>>>

[jira] [Created] (IGNITE-14294) .NET: ClientServerCompatibilityTest is flaky

[Pavel Tupitsyn (Jira)]

Pavel Tupitsyn created IGNITE-14294:
---

 Summary: .NET: ClientServerCompatibilityTest is flaky
 Key: IGNITE-14294
 URL: https://issues.apache.org/jira/browse/IGNITE-14294
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.11


ClientServerCompatibilityTest fails for two reasons:

1. {{Failed to establish Ignite thin client connection, examine inner 
exceptions for details. (Connection refused 127.0.0.1:10892)}} - check process 
output, is there a different port used for the client connector?

2. {{GridUnsafe cannot access class jdk.internal.misc.SharedSecrets}} - we 
should pass {{--add-exports}} and {{--illegal-access=permit}} JVM options when 
running on Java9+, see {{Jvm.IsJava9}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Azure Cloud IP Finder

[Denis Magda]

Atri,

Let's discuss the subj together with the community. Ignite already supports
AWS [1] and GCE [2] IP Finders out of the box, but the Azure one is still
missing. I can confirm that the demand exists, and rather frequently, I see
developers asking for an Azure-native IP finder for Ignite.

Atri, could you please research how to implement the IP finder and suggest
a solution in this discussion thread? See how it was done for AWS and GCE,
we might go the same route or use a more contemporary and easy-to-configure
approach for Azure.

[1]
https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#amazon-s3-ip-finder
[2]
https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#google-compute-discovery

-
Denis

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

[Denis Magda]

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

-
Denis


On Fri, Mar 5, 2021 at 1:09 PM Maxim Muzafarov  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: IGNITE-2399 : Asynchronous Acquire method in IgniteSemaphore

[Valentin Kulichenko]

Hi Atri,

First and foremost, we need to clarify the API for this functionality.
There are two options presented in the ticket, but no clear decision about
which one should be used. I personally think that the original signature
(the one in the ticket description) makes more sense, but it looks like
you've implemented an alternative suggested in the comments. What was your
motivation behind that?

As for where the method can be located, I'm OK if we add it directly to the
IgniteSemaphore interface.

-Val

On Tue, Mar 9, 2021 at 8:22 AM Atri Sharma  wrote:

> Gentle ping
>
> On Mon, 8 Mar 2021, 13:51 Atri Sharma,  wrote:
>
> > Hi All,
> >
> > I would like to start a discussion around IGNITE-2399.
> >
> > Background: The typical use of IgniteSemaphore consists of acquiring
> > the semaphore, performing the task and releasing the semaphore. This
> > JIRA proposes a new method which will accept a callable, acquire the
> > semaphore, and return a future. Upon completion of the future, the
> > semaphore is released.
> >
> > This API seems useful for an easy encapsulation of the described use
> > case and does not cause an internal flux since all the changes are
> > focused at the public API.
> >
> > WIP PR for the same:
> >
> > https://github.com/apache/ignite/pull/8820
> >
> > Please share your thoughts and comments.
> >
> > --
> > Regards,
> >
> > Atri
> > Apache Concerted
> >
>

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

[Valentin Kulichenko]

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  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: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)

[Ilya Kasnacheev]

Hello!

Unless we do extra checks for Windows environment, I suggest merging
IGNITE-14284 

Regards,
-- 
Ilya Kasnacheev


вт, 9 мар. 2021 г. в 20:26, Maxim Muzafarov :

> Folks,
>
>
> Sharing the release status:
>
> .NET: AffinityKey does not work - In-Progress
> https://issues.apache.org/jira/browse/IGNITE-14293
>
> sqlline: `Property "url" is required' - Patch Available
> https://issues.apache.org/jira/browse/IGNITE-14284
>
> sqllline: `Bad history file syntax!' - Resolved
> https://issues.apache.org/jira/browse/IGNITE-14285
>
>
> I'd like to cherry-pick the following fixed bugs to the 2.10 release
> branch.
> Do you have any objections?
>
> IGNITE-14250 .NET: Fix race condition in Events example, test example
> output
> https://issues.apache.org/jira/browse/IGNITE-14250
>
> IGNITE-14168 fix description of validate_indexes command (#8798)
> https://issues.apache.org/jira/browse/IGNITE-14168
>
> IGNITE-14138 Fixed an issue where historical rebalance can kill
> supplier node. Fixes #8769
> https://issues.apache.org/jira/browse/IGNITE-14138
>
> On Mon, 1 Mar 2021 at 21:26, Maxim Muzafarov  wrote:
> >
> > Igor,
> >
> > Many thanks for fixing the issue!
> > I've cherry-picked it to the 2.10 branch.
> >
> > Folks,
> >
> > I'll finalize the latest changes for the documentation pages and
> > prepare the rc build shortly.
> >
> > On Mon, 1 Mar 2021 at 21:08, Igor Sapego  wrote:
> > >
> > > The following commit should be cherry-picked:
> 0675e2a7e800730c9c8230332b82809754ddae5a
> > >
> > > Sorry for a delay.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, Mar 1, 2021 at 9:06 PM Igor Sapego  wrote:
> > >>
> > >> Maxim,
> > >>
> > >> The issue is fixed and is merged to master now.
> > >>
> > >> Best Regards,
> > >> Igor
> > >>
> > >>
> > >> On Sun, Feb 28, 2021 at 8:12 PM Maxim Muzafarov 
> wrote:
> > >>>
> > >>> Hello Igor,
> > >>>
> > >>> >  I believe I could fix the ticket [1] by the end of the next week.
> > >>> Should we still wait a bit for t his fix or postpone it to 2.10.1?
> WDYT?
> > >>>
> > >>>
> > >>>
> > >>> [1] https://issues.apache.org/jira/browse/IGNITE-14204
> > >>>
> > >>> On Fri, 26 Feb 2021 at 11:20, Max Timonin 
> wrote:
> > >>> >
> > >>> > Hi, Maxim!
> > >>> >
> > >>> > The bug IGNITE-14206 [1] fixed. There are 2 commits to cherry-pick
> > >>> >
> > >>> > 1.
> > >>> >
> https://github.com/apache/ignite/commit/851f650ba03e0b6c081cfe23f411fd2bf6be0228
> > >>> > 2.
> > >>> >
> https://github.com/apache/ignite/commit/93b74922bd04b164301d7bc5a2788b9693d4a8a4
> > >>> >
> > >>> >
> > >>> > https://issues.apache.org/jira/browse/IGNITE-14206
> > >>> >
> > >>> > On Wed, Feb 24, 2021 at 5:47 PM Maxim Muzafarov 
> wrote:
> > >>> >
> > >>> > > Anton,
> > >>> > >
> > >>> > > Your improvement is very important, for sure, but it's almost 2
> months
> > >>> > > have passed since the initiation of the release branch. I think
> we
> > >>> > > should prepare the changes as fast as possible for now and
> initiate
> > >>> > > with the next one release. In general, it would be nice to have a
> > >>> > > release plan for the year ahead so each developer will
> understand on
> > >>> > > which release his changes can get into.
> > >>> > >
> > >>> > > That's why I'm going to prepare an RC-build on Monday 1-st March.
> > >>> > >
> > >>> > > On Wed, 24 Feb 2021 at 11:13, Anton Vinogradov 
> wrote:
> > >>> > > >
> > >>> > > > Maxim,
> > >>> > > >
> > >>> > > > https://issues.apache.org/jira/browse/IGNITE-13873
> > >>> > > > Is ready for review, is it possible to wait for it?
> > >>> > > >
> > >>> > > > On Wed, Feb 24, 2021 at 12:01 AM Maxim Muzafarov <
> mmu...@apache.org>
> > >>> > > wrote:
> > >>> > > >
> > >>> > > > > Folks,
> > >>> > > > >
> > >>> > > > >
> > >>> > > > > I'd like to cherry-pick to the release branch the following
> fixes:
> > >>> > > > >
> > >>> > > > > Fix security context for JDBC bulk-load operations
> > >>> > > > > https://issues.apache.org/jira/browse/IGNITE-13472
> > >>> > > > >
> > >>> > > > > Fixed an issue that caused a deadlock when user cache was
> created in
> > >>> > > > > parallel with TTL worker was in progress.
> > >>> > > > > https://issues.apache.org/jira/browse/IGNITE-14078
> > >>> > > > >
> > >>> > > > > On Thu, 18 Feb 2021 at 20:26, Maxim Muzafarov <
> mmu...@apache.org>
> > >>> > > wrote:
> > >>> > > > > >
> > >>> > > > > > Maxim, Igor,
> > >>> > > > > >
> > >>> > > > > > Thanks for sharing details.
> > >>> > > > > > Let's wait for these fixes.
> > >>> > > > > >
> > >>> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14206
> > >>> > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-14204
> > >>> > > > > >
> > >>> > > > > > On Thu, 18 Feb 2021 at 18:35, Igor Sapego <
> isap...@apache.org>
> > >>> > > wrote:
> > >>> > > > > > >
> > >>> > > > > > > Maxim,
> > >>> > > > > > >
> > >>> > > > > > > I believe I could fix the ticket [1] by the end of the
> next week.
> > >>> > > > > > >
> > >>> > > > > > >