Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

That name will definitely confuse Jira users.

Let's stick to basic devision by 2.x and 3.x — it seems most intuitive and has 
lots of examples inside ASF, look at the Tomcat for instance.

> On 25 Sep 2021, at 21:05, Saikat Maitra  wrote:
> 
> Hi,
> 
> I like the major version update like Ignite 3.0 but if we were to come up
> with a name my other suggestion would be
> 
> Ignite-kernel
> 
> kernel - for the central or most important part of something
> 
> Also taken references from Compute kernel - a routine compiled for high
> throughput accelerators
> 
> https://en.wikipedia.org/wiki/Compute_kernel
> 
> Regards,
> Saikat
> 
> 
> On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> 
>> Kafka and Spark didn't split codebases (at least to my knowledge).
>> Separating codebases was the fundamental step, everything else is a
>> technicality.
>> 
>> Having said that, I will be OK with your suggestion as I don't really see a
>> difference, although I'm not sure we will be able to come up with a name
>> that is more intuitive than a separate project :)
>> 
>> Let's see what others think.
>> 
>> -Val
>> 
>> On Sat, Sep 25, 2021 at 12:23 AM Denis Magda  wrote:
>> 
>>> Moving the discussion back to the dev list.
>>> 
>>> Val, Andrey, for that purpose we can ask INFRA to create a
>>> special mandatory field such as "Architecture" with two predefined
>> values -
>>> "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs to be
>>> intuitive enough even for users who submit issues. What disturbs me is
>> that
>>> neither Kafka nor Spark have a different project for the recently
>> released
>>> versions 3. A different GitHub project is not that disturbing.
>>> 
>>> -
>>> Denis
>>> 
>>> 
>>> On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>> 
 Denis,
 
 From a purely technical perspective, these are indeed two separate
 projects, because they are based on different codebases. The split
>> you're
 talking about happened a year ago, when we created the repo for Ignite
>> 3.
 This significantly differs from the 1.x->2.x transition, as these two
 shared the codebase.
 
 For the same reason, a bug filed for 2.x can't be just transitioned to
 3.x. It will either not exist in 3.x in the first place, or will
>> require
>>> a
 completely different fix, which will mean two different tickets.
 
 That said, I still believe that Ignite 2 and Ignite 3 are just
>> different
 versions of the same product, because, as you correctly mentioned, they
 target "same users, community, use cases". At the same time, they are
 developed as different projects on the technical level. Let's not
>> confuse
 these two aspects with each other - they are largely orthogonal.
 
 At this point, creating a Jira project doesn't change anything
 fundamentally. It's only about ease of use of our tooling and efficient
 ticket management.
 
 -Val
 
 On Thu, Sep 23, 2021 at 10:15 PM Denis Magda 
>> wrote:
 
> Folks, you confuse me. I've never treated Ignite 3 as a different
> project. It's the same Ignite (distributed database for
>> high-performance
> computing...) but on a modernized architecture and APIs - thus, a
>> major
> version. Same users, community, use cases.
> 
> But, I'm against separate JIRA or Confluence projects. This is how
>>> you're
> truly stepping on a project-split path. When we used to work on Ignite
>>> 2 we
> could live within the same JIRA space with Ignite 1. Moreover, many
>>> tickets
> that are filed against Ignite 2 can be fixed in Ignite 3 only - which
>>> is a
> version change in our JIRA.
> 
> So, -1 from me for the separate JIRA proposal.
> 
> -
> Denis
> 
> 
> On Wed, Sep 22, 2021 at 8:23 AM Maxim Muzafarov 
> wrote:
> 
>> Val,
>> 
>> I don't see any issues having different projects under Ignite's brand
>> from the developer's side except the versioning issue. This is a bad
>> case when two different projects must have dependent versions and
>> even
>> worse when some marketing things affect the development and release
>> processes.
>> 
>> I agree with Nikolay and Ilya - the right way here is having
>> "Ignite" and versioning started from zero. However,
>> both
>> of Ignite's can easily co-exist.
>> 
>> On Tue, 21 Sept 2021 at 22:13, Valentin Kulichenko
>>  wrote:
>>> 
>>> Ilya,
>>> 
>>> What exactly is this different focus and different values? Why
>>> exactly
>> do you think Ignite 3 will never cover all the current features? And
>>> why is
>> this the criteria in the first place? I work on both Ignite 2 and
>>> Ignite 3
>> almost every day and I simply don't think all this is true. I
>> honestly
>> can't understand what this fuss is all about.
>>> 
>>

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Ivan Pavlukhin]

Today it is quite common to use calendar-based versioning scheme, e.g.
[1]. We can consider it for Ignite 3. Luckily versions will not clash.

[1] https://www.cockroachlabs.com/docs/releases/index.html

2021-09-27 10:49 GMT+03:00, Petr Ivanov :
> That name will definitely confuse Jira users.
>
> Let's stick to basic devision by 2.x and 3.x — it seems most intuitive and
> has lots of examples inside ASF, look at the Tomcat for instance.
>
>> On 25 Sep 2021, at 21:05, Saikat Maitra  wrote:
>>
>> Hi,
>>
>> I like the major version update like Ignite 3.0 but if we were to come up
>> with a name my other suggestion would be
>>
>> Ignite-kernel
>>
>> kernel - for the central or most important part of something
>>
>> Also taken references from Compute kernel - a routine compiled for high
>> throughput accelerators
>>
>> https://en.wikipedia.org/wiki/Compute_kernel
>>
>> Regards,
>> Saikat
>>
>>
>> On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>>
>>> Kafka and Spark didn't split codebases (at least to my knowledge).
>>> Separating codebases was the fundamental step, everything else is a
>>> technicality.
>>>
>>> Having said that, I will be OK with your suggestion as I don't really see
>>> a
>>> difference, although I'm not sure we will be able to come up with a name
>>> that is more intuitive than a separate project :)
>>>
>>> Let's see what others think.
>>>
>>> -Val
>>>
>>> On Sat, Sep 25, 2021 at 12:23 AM Denis Magda  wrote:
>>>
 Moving the discussion back to the dev list.

 Val, Andrey, for that purpose we can ask INFRA to create a
 special mandatory field such as "Architecture" with two predefined
>>> values -
 "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs to
 be
 intuitive enough even for users who submit issues. What disturbs me is
>>> that
 neither Kafka nor Spark have a different project for the recently
>>> released
 versions 3. A different GitHub project is not that disturbing.

 -
 Denis


 On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko <
 valentin.kuliche...@gmail.com> wrote:

> Denis,
>
> From a purely technical perspective, these are indeed two separate
> projects, because they are based on different codebases. The split
>>> you're
> talking about happened a year ago, when we created the repo for Ignite
>>> 3.
> This significantly differs from the 1.x->2.x transition, as these two
> shared the codebase.
>
> For the same reason, a bug filed for 2.x can't be just transitioned to
> 3.x. It will either not exist in 3.x in the first place, or will
>>> require
 a
> completely different fix, which will mean two different tickets.
>
> That said, I still believe that Ignite 2 and Ignite 3 are just
>>> different
> versions of the same product, because, as you correctly mentioned,
> they
> target "same users, community, use cases". At the same time, they are
> developed as different projects on the technical level. Let's not
>>> confuse
> these two aspects with each other - they are largely orthogonal.
>
> At this point, creating a Jira project doesn't change anything
> fundamentally. It's only about ease of use of our tooling and
> efficient
> ticket management.
>
> -Val
>
> On Thu, Sep 23, 2021 at 10:15 PM Denis Magda 
>>> wrote:
>
>> Folks, you confuse me. I've never treated Ignite 3 as a different
>> project. It's the same Ignite (distributed database for
>>> high-performance
>> computing...) but on a modernized architecture and APIs - thus, a
>>> major
>> version. Same users, community, use cases.
>>
>> But, I'm against separate JIRA or Confluence projects. This is how
 you're
>> truly stepping on a project-split path. When we used to work on
>> Ignite
 2 we
>> could live within the same JIRA space with Ignite 1. Moreover, many
 tickets
>> that are filed against Ignite 2 can be fixed in Ignite 3 only - which
 is a
>> version change in our JIRA.
>>
>> So, -1 from me for the separate JIRA proposal.
>>
>> -
>> Denis
>>
>>
>> On Wed, Sep 22, 2021 at 8:23 AM Maxim Muzafarov 
>> wrote:
>>
>>> Val,
>>>
>>> I don't see any issues having different projects under Ignite's
>>> brand
>>> from the developer's side except the versioning issue. This is a bad
>>> case when two different projects must have dependent versions and
>>> even
>>> worse when some marketing things affect the development and release
>>> processes.
>>>
>>> I agree with Nikolay and Ilya - the right way here is having
>>> "Ignite" and versioning started from zero. However,
>>> both
>>> of Ignite's can easily co-exist.
>>>
>>> On Tue, 21 Sept 2021 at 22:13, Valentin Kulichenko
>>>  wrote:

 Ilya,

 What exa

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

How will not they clash if version is based only on date?

> On 27 Sep 2021, at 14:33, Ivan Pavlukhin  wrote:
> 
> Today it is quite common to use calendar-based versioning scheme, e.g.
> [1]. We can consider it for Ignite 3. Luckily versions will not clash.
> 
> [1] https://www.cockroachlabs.com/docs/releases/index.html
> 
> 2021-09-27 10:49 GMT+03:00, Petr Ivanov :
>> That name will definitely confuse Jira users.
>> 
>> Let's stick to basic devision by 2.x and 3.x — it seems most intuitive and
>> has lots of examples inside ASF, look at the Tomcat for instance.
>> 
>>> On 25 Sep 2021, at 21:05, Saikat Maitra  wrote:
>>> 
>>> Hi,
>>> 
>>> I like the major version update like Ignite 3.0 but if we were to come up
>>> with a name my other suggestion would be
>>> 
>>> Ignite-kernel
>>> 
>>> kernel - for the central or most important part of something
>>> 
>>> Also taken references from Compute kernel - a routine compiled for high
>>> throughput accelerators
>>> 
>>> https://en.wikipedia.org/wiki/Compute_kernel
>>> 
>>> Regards,
>>> Saikat
>>> 
>>> 
>>> On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>> 
 Kafka and Spark didn't split codebases (at least to my knowledge).
 Separating codebases was the fundamental step, everything else is a
 technicality.
 
 Having said that, I will be OK with your suggestion as I don't really see
 a
 difference, although I'm not sure we will be able to come up with a name
 that is more intuitive than a separate project :)
 
 Let's see what others think.
 
 -Val
 
 On Sat, Sep 25, 2021 at 12:23 AM Denis Magda  wrote:
 
> Moving the discussion back to the dev list.
> 
> Val, Andrey, for that purpose we can ask INFRA to create a
> special mandatory field such as "Architecture" with two predefined
 values -
> "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs to
> be
> intuitive enough even for users who submit issues. What disturbs me is
 that
> neither Kafka nor Spark have a different project for the recently
 released
> versions 3. A different GitHub project is not that disturbing.
> 
> -
> Denis
> 
> 
> On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> 
>> Denis,
>> 
>> From a purely technical perspective, these are indeed two separate
>> projects, because they are based on different codebases. The split
 you're
>> talking about happened a year ago, when we created the repo for Ignite
 3.
>> This significantly differs from the 1.x->2.x transition, as these two
>> shared the codebase.
>> 
>> For the same reason, a bug filed for 2.x can't be just transitioned to
>> 3.x. It will either not exist in 3.x in the first place, or will
 require
> a
>> completely different fix, which will mean two different tickets.
>> 
>> That said, I still believe that Ignite 2 and Ignite 3 are just
 different
>> versions of the same product, because, as you correctly mentioned,
>> they
>> target "same users, community, use cases". At the same time, they are
>> developed as different projects on the technical level. Let's not
 confuse
>> these two aspects with each other - they are largely orthogonal.
>> 
>> At this point, creating a Jira project doesn't change anything
>> fundamentally. It's only about ease of use of our tooling and
>> efficient
>> ticket management.
>> 
>> -Val
>> 
>> On Thu, Sep 23, 2021 at 10:15 PM Denis Magda 
 wrote:
>> 
>>> Folks, you confuse me. I've never treated Ignite 3 as a different
>>> project. It's the same Ignite (distributed database for
 high-performance
>>> computing...) but on a modernized architecture and APIs - thus, a
 major
>>> version. Same users, community, use cases.
>>> 
>>> But, I'm against separate JIRA or Confluence projects. This is how
> you're
>>> truly stepping on a project-split path. When we used to work on
>>> Ignite
> 2 we
>>> could live within the same JIRA space with Ignite 1. Moreover, many
> tickets
>>> that are filed against Ignite 2 can be fixed in Ignite 3 only - which
> is a
>>> version change in our JIRA.
>>> 
>>> So, -1 from me for the separate JIRA proposal.
>>> 
>>> -
>>> Denis
>>> 
>>> 
>>> On Wed, Sep 22, 2021 at 8:23 AM Maxim Muzafarov 
>>> wrote:
>>> 
 Val,
 
 I don't see any issues having different projects under Ignite's
 brand
 from the developer's side except the versioning issue. This is a bad
 case when two different projects must have dependent versions and
 even
 worse when some marketing things affect the development and release
 processes.
 
 I agre

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Ivan Pavlukhin]

I mean that Ignite 2.x will continue to use old scheme and Ignite 3
will be e.g. Ignite 21.1 and so on.

2021-09-27 14:57 GMT+03:00, Petr Ivanov :
> How will not they clash if version is based only on date?
>
>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin  wrote:
>>
>> Today it is quite common to use calendar-based versioning scheme, e.g.
>> [1]. We can consider it for Ignite 3. Luckily versions will not clash.
>>
>> [1] https://www.cockroachlabs.com/docs/releases/index.html
>>
>> 2021-09-27 10:49 GMT+03:00, Petr Ivanov :
>>> That name will definitely confuse Jira users.
>>>
>>> Let's stick to basic devision by 2.x and 3.x — it seems most intuitive
>>> and
>>> has lots of examples inside ASF, look at the Tomcat for instance.
>>>
 On 25 Sep 2021, at 21:05, Saikat Maitra 
 wrote:

 Hi,

 I like the major version update like Ignite 3.0 but if we were to come
 up
 with a name my other suggestion would be

 Ignite-kernel

 kernel - for the central or most important part of something

 Also taken references from Compute kernel - a routine compiled for high
 throughput accelerators

 https://en.wikipedia.org/wiki/Compute_kernel

 Regards,
 Saikat


 On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko <
 valentin.kuliche...@gmail.com> wrote:

> Kafka and Spark didn't split codebases (at least to my knowledge).
> Separating codebases was the fundamental step, everything else is a
> technicality.
>
> Having said that, I will be OK with your suggestion as I don't really
> see
> a
> difference, although I'm not sure we will be able to come up with a
> name
> that is more intuitive than a separate project :)
>
> Let's see what others think.
>
> -Val
>
> On Sat, Sep 25, 2021 at 12:23 AM Denis Magda 
> wrote:
>
>> Moving the discussion back to the dev list.
>>
>> Val, Andrey, for that purpose we can ask INFRA to create a
>> special mandatory field such as "Architecture" with two predefined
> values -
>> "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs
>> to
>> be
>> intuitive enough even for users who submit issues. What disturbs me
>> is
> that
>> neither Kafka nor Spark have a different project for the recently
> released
>> versions 3. A different GitHub project is not that disturbing.
>>
>> -
>> Denis
>>
>>
>> On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>>
>>> Denis,
>>>
>>> From a purely technical perspective, these are indeed two separate
>>> projects, because they are based on different codebases. The split
> you're
>>> talking about happened a year ago, when we created the repo for
>>> Ignite
> 3.
>>> This significantly differs from the 1.x->2.x transition, as these
>>> two
>>> shared the codebase.
>>>
>>> For the same reason, a bug filed for 2.x can't be just transitioned
>>> to
>>> 3.x. It will either not exist in 3.x in the first place, or will
> require
>> a
>>> completely different fix, which will mean two different tickets.
>>>
>>> That said, I still believe that Ignite 2 and Ignite 3 are just
> different
>>> versions of the same product, because, as you correctly mentioned,
>>> they
>>> target "same users, community, use cases". At the same time, they
>>> are
>>> developed as different projects on the technical level. Let's not
> confuse
>>> these two aspects with each other - they are largely orthogonal.
>>>
>>> At this point, creating a Jira project doesn't change anything
>>> fundamentally. It's only about ease of use of our tooling and
>>> efficient
>>> ticket management.
>>>
>>> -Val
>>>
>>> On Thu, Sep 23, 2021 at 10:15 PM Denis Magda 
> wrote:
>>>
 Folks, you confuse me. I've never treated Ignite 3 as a different
 project. It's the same Ignite (distributed database for
> high-performance
 computing...) but on a modernized architecture and APIs - thus, a
> major
 version. Same users, community, use cases.

 But, I'm against separate JIRA or Confluence projects. This is how
>> you're
 truly stepping on a project-split path. When we used to work on
 Ignite
>> 2 we
 could live within the same JIRA space with Ignite 1. Moreover, many
>> tickets
 that are filed against Ignite 2 can be fixed in Ignite 3 only -
 which
>> is a
 version change in our JIRA.

 So, -1 from me for the separate JIRA proposal.

 -
 Denis


 On Wed, Sep 22, 2021 at 8:23 AM Maxim Muzafarov 
 wrote:

> Val,
>
> I don't see any issues having 

Updating Javascript npm Package

[Kevin Corbett]

Hello Igniters!

I’ve been helping with the Ignite social media channels for the last month now. 
Lately I’ve been trying to increase awareness of our Javascript capabilities, 
namely the thin client. Someone on our Twitter page had mentioned the npm 
package hasn’t been updated in 3 years (!)

I see our Github for the thin client was last updated in January this year. 
What can we do to get this updated? 
https://www.npmjs.com/package/apache-ignite-client 


Also, I saw there was an attempt to add Apache Ignite support to TypeORM but 
there were many issues with the client.
https://github.com/typeorm/typeorm/pull/7012

Re: Updating Javascript npm Package

[Ivan Daschinsky]

Hi! I can share my experience how to drive this activity. Personally, I've
driven four recent releases of python thin client (pyignite). First of all,
you should start a discussion, this thread is a good place to start.
Secondly, you should prepare release branch (with help of commiters),
create realease notes, etc. Secondly, PMC member should prepare rc
artifact, sign with signature, theb publish it in apache svn for voting.
After successful voting, release artifact can be published to npmjs.

Let's start this activity!

пн, 27 сент. 2021 г., 18:52 Kevin Corbett :

> Hello Igniters!
>
> I’ve been helping with the Ignite social media channels for the last month
> now. Lately I’ve been trying to increase awareness of our Javascript
> capabilities, namely the thin client. Someone on our Twitter page had
> mentioned the npm package hasn’t been updated in 3 years (!)
>
> I see our Github for the thin client was last updated in January this
> year. What can we do to get this updated?
> https://www.npmjs.com/package/apache-ignite-client <
> https://www.npmjs.com/package/apache-ignite-client>
>
> Also, I saw there was an attempt to add Apache Ignite support to TypeORM
> but there were many issues with the client.
> https://github.com/typeorm/typeorm/pull/7012

Re: [RESULT][VOTE] Release Apache Ignite 2.11.0 RC2

[Pavel Tupitsyn]

Blog about Ignite.NET changes:
https://ptupitsyn.github.io/Whats-New-In-Ignite-Net-2.11/

On Fri, Sep 24, 2021 at 2:32 PM Alexandr Shapkin 
wrote:

> Hello!
>
> Since the new release comes with more modules extracted into the
> extensions repo, I think it’s vital to update them as well. Consider
> SpringTransactionManager which is now a part of ignite-spring-tx-ext [1]
> that hasn’t been released yet. At least I failed to find any maven
> artifacts published. Am I missing something?
>
> [1] -
> https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-tx#maven-configuration
>
>
> > On 23 Sep 2021, at 18:49, Dmitry Pavlov  wrote:
> >
> > Thanks to Maxim and kudos to Alexey Gidaspov, who was serving role of
> Release manager during all init, rampdown and stabilization phase.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > On 2021/09/21 09:01:55, Pavel Tupitsyn  wrote:
> >> Maxim,
> >>
> >> I'll prepare a dedicated blog post about Ignite.NET changes later this
> week.
> >> Thanks for driving the release!
> >>
> >> On Mon, Sep 20, 2021 at 11:20 PM Maxim Muzafarov 
> wrote:
> >>
> >>> Denis,
> >>>
> >>> The post is added:
> >>> https://blogs.apache.org/ignite/entry/apache-ignite-2-11-stabilization
> >>>
> >>> I've fixed the image according to your suggestions.
> >>>
> >>> On Mon, 20 Sept 2021 at 21:35, Denis Magda  wrote:
> 
>  Maxim, thanks for driving the release and preparing the announcement
>  article!
> 
>  A few questions:
> 
>    - Should "dev" be replaced with "2.11" on the picture of the
> cellular
>    clusters deployment section?
>    - Will the article be published on our blogs.apache.org page?
> 
>  -
>  Denis
> 
> 
>  On Sat, Sep 18, 2021 at 9:36 PM Maxim Muzafarov 
> >>> wrote:
> 
> > Pavel,
> >
> >
> > I've prepared a draft blog post [1] for the 2.11 release announcement
> > message, however, this post doesn't include changes related to the
> > .NET part of the Apache Ignite. Will you prepare a dedicated post
> > related to the .NET changes or I should include them in this one?
> >
> > Folks,
> > all the comments are welcome.
> >
> >
> > [1]
> >
> >>>
> https://github.com/Mmuzaf/mmuzaf.github.io/blob/main/_post/Release_Newsletter_211.md
> >
> >
> > On Thu, 16 Sept 2021 at 17:21, Maxim Muzafarov 
> >>> wrote:
> >>
> >> Hello, Igniters!
> >>
> >> Apache Ignite 2.11.0 release (RC2) has been accepted.
> >>
> >> 5 - "+1" votes received.
> >> 1 - "+0,5" vote received.
> >>
> >> Here are the votes received:
> >>
> >> - Pavel Tupitsyn (binding)
> >> - Alex Plehanov (binding)
> >> - Nikolay Izhikov (binding)
> >> - Ilya Kasnacheev
> >> - Ivan Daschinsky
> >> - Zhenya Stanilovsky
> >>
> >>
> >> Here is the link to the voting thread -
> >>
> >
> >>>
> https://lists.apache.org/thread.html/rab233aa7d737b84b678fb74c81a867e3aad270471a2aac85a4d35cb8%40%3Cdev.ignite.apache.org%3E
> >>
> >> Thank you!
> >
> >>>
> >>
>
>