Generation is a good one.
Also we can use variant from DEB packaging versioning — EPOCH.
> On 17 Oct 2021, at 02:52, Valentin Kulichenko
> wrote:
>
> Folks,
>
> Since there are controversial opinions regarding the topic, I've cancelled
> the vote and would like to resurrect the discussion.
>
Folks,
Since there are controversial opinions regarding the topic, I've cancelled
the vote and would like to resurrect the discussion.
There are a couple of items that I would like to hear your opinions on.
1. I still propose to have a separate Confluence space for Ignite 3. This
makes total
Sorry, If I missed something in the thread but in case of a separate
JIRA project how are users supposed to create e.g. bug tickets? How
can we make sure that users will not use a wrong JIRA project often?
2021-10-05 2:50 GMT+03:00, Valentin Kulichenko :
> Ivan,
>
> I'm not pushing, I'm trying to
Ivan,
I'm not pushing, I'm trying to apply the lazy consensus. It soon will be a
whole month since I've started the discussion - more than enough to express
concerns and provide alternative suggestions. Please keep in mind that we
are trying to address a very specific technical problem that
Val,
> Let's discuss this until the end of the week. If there is no clear picture on
> option #2 by then, I suggest we go with #1.
For a moment I felt that the proposal is pushed. Let's not do so. The
subject is very important, years impact I suppose. And the best way
here is to reach absolute
I am watching how Apache Ignite does evolve for over a 3 years already and see
that such hidden (almost no Open Source Community points could be achieved for
refactoring and addressing something that is not directly project's source
executable code) issues drown under constant pressure of new
> — issues related to Maven build? possible Gradle upgrade?
I’m not aware of the issues.
Can you, please, send a tickets or description of existing issues?
Anyway, it seems change of build tool can be done at any time we want
> — issues related to run scripts?
> — issues related to release and
And what about:
— issues related to Maven build? possible Gradle upgrade?
— issues related to run scripts?
— issues related to release and delivery processes and scripts?
Are they going to be addressed during Apache Ignite evolution too?
> On 29 Sep 2021, at 13:47, Nikolay Izhikov wrote:
>
> Does you vision of evolutionary improvement involve technical debt addressing
Yes, of course.
My vision was the following (from the bird eye):
- 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User API
doesn’t change).
- 2.30 - replace static XML configuration with the
> I believe that we should improve Ignite evolutionary and not revolutionary.
> First of all, change user API with the slow improvements step by step.
Nikolay,
Does you vision of evolutionary improvement involve technical debt addressing?
>
>
>> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev
Hello, Valentin.
> Nikolay, Ilya, Denis, and others who opposed the initial suggestion
It seems I don’t write my point clear.
I’m +1 to have another jira project for Ignite3.
My point is - Ignite3 is not Ignite - it just another database engine.
> Ignite 2 and Ignite 3 are *technically*
Hello!
If we go the second route, we can call the field "Generation".
Generation: Ignite 2.x
Generation: Ignite 3
(no new tickets should ever be filed for Ignite 1.x but if they are, they
should go to the first Generation)
Regards.
--
Ilya Kasnacheev
ср, 29 сент. 2021 г. в 00:33, Valentin
As for the original topic, we need to come to a solution. Let me summarize
what we've discussed so far.
-PROBLEM-
Ignite 3 is the next major version of Apache Ignite. It targets the same
use cases and provides a similar set of features as Ignite 2. At the same
time, Ignite 2 and Ignite 3 are
Folks,
Versioning is a separate topic. We agreed on the current scheme in March
[1]. If someone thinks we need to change it, please create a new thread and
present your suggestions.
[1]
Seems rational.
But still 2.11.0 and 21.1.0 for the time being will look like similar or error
in either version...
> On 27 Sep 2021, at 18:11, Ivan Pavlukhin wrote:
>
> 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
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
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]
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.
>
>
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
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
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
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
Dmitry,
Thanks! Sure, this is not super urgent. Please let us know when this is
ready.
And feel free to ask me any questions if you have any.
-Val
On Tue, Sep 21, 2021 at 5:13 PM Dmitry Pavlov wrote:
> Ok, if nobody minds, I'll create spaces a bit later.
>
> I hope it is not too urgent.
>
>
Ok, if nobody minds, I'll create spaces a bit later.
I hope it is not too urgent.
Sincerely,
Dmitriy Pavlov
On 2021/09/21 10:37:42, Valentin Kulichenko
wrote:
> Hi Dmitry,
>
> According to Infra, this has to be done through http://selfserve.apache.org/,
> but only PMC chairs have access.
>
Hi Dmitry,
According to Infra, this has to be done through http://selfserve.apache.org/,
but only PMC chairs have access.
Could you please assist with the creation of the Jira project and
Confluence space?
-Val
On Tue, Sep 21, 2021 at 10:46 AM Valentin Kulichenko <
Infra requests created:
- https://issues.apache.org/jira/browse/INFRA-22349
- https://issues.apache.org/jira/browse/INFRA-22350
-Val
On Mon, Sep 20, 2021 at 10:50 AM Petr Ivanov wrote:
> +1
>
> Since we've agreed that there are two projects (that are Ignite2 and
> Ignite3), separate
+1
Since we've agreed that there are two projects (that are Ignite2 and Ignite3),
separate development environments seem to be logical and natural course of
things.
> On 18 Sep 2021, at 12:42, Alexander Polovtcev wrote:
>
> +1
> This is a welcome proposal, because we already have some
+1
This is a welcome proposal, because we already have some pending Ignite 3
specific documents, and it is not clear where to put them at the moment.
On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Igniters,
>
> I think it's clear to all of us that
Huge +1.
сб, 18 сент. 2021 г., 04:22 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:
> Igniters,
>
> I think it's clear to all of us that Ignite 2.x and 3.x will coexist for a
> while. They are developed in separate Git repos, but we still accumulate
> the tickets for both versions in the
+1
--
Nikita Ivanov
On Fri, Sep 17, 2021 at 6:22 PM Valentin Kulichenko
wrote:
>
> Igniters,
>
> I think it's clear to all of us that Ignite 2.x and 3.x will coexist for a
> while. They are developed in separate Git repos, but we still accumulate
> the tickets for both versions in the same Jira
Igniters,
I think it's clear to all of us that Ignite 2.x and 3.x will coexist for a
while. They are developed in separate Git repos, but we still accumulate
the tickets for both versions in the same Jira project, which seems to
complicate the ticket management.
For example, we use the
31 matches
Mail list logo
