> — 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 delivery processes and scripts? I’m not aware of those too. Can you point to then, please? > Are they going to be addressed during Apache Ignite evolution too? Yes, from my point of view. > 29 сент. 2021 г., в 14:03, Petr Ivanov <mr.wei...@gmail.com> написал(а): > > 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 <nizhi...@apache.org> 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 new dynamic approach. >> - 2.40 - replace H2 SQL engine with the Calcite >> >> etc. >> >> Versions depends on feature readiness. >> >> Anyway, I step back with the initial Ignite3 development, because, don’t >> want to interfere the progress. >> >> Respect to the developers who have courage to develop such complex things >> from scratch. >> >>> 29 сент. 2021 г., в 12:55, Petr Ivanov <mr.wei...@gmail.com> написал(а): >>> >>> >>>> 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 <ilya.kasnach...@gmail.com> >>>>> написал(а): >>>>> >>>>> 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 Kulichenko < >>>>> valentin.kuliche...@gmail.com>: >>>>> >>>>>> 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 *technically* separate projects. They are >>>>>> developed in different repositories (and therefore are based on different >>>>>> codebases) and implement different internal architectures. To achieve a >>>>>> more efficient development process, we need to create a clear separation >>>>>> between 2.x and 3.x within *development resources* (Jira and Confluence). >>>>>> >>>>>> -POSSIBLE SOLUTIONS- >>>>>> >>>>>> 1. Create a separate Jira project and Confluence space for Ignite 3 >>>>>> (initial suggestion). >>>>>> 2. Add a *mandatory* field in Jira to identify whether a ticket belongs >>>>>> to >>>>>> 2.x or 3.x. >>>>>> >>>>>> If we go with #2, there are still several things to figure out: >>>>>> >>>>>> - What is the name of this field? It needs to be intuitive to anyone who >>>>>> joins the community. >>>>>> - We need to make sure that Ignite 3 tickets are not mapped to 2.x >>>>>> versions, and vice versa. Can we restrict this in Jira? Or we will have >>>>>> to >>>>>> monitor this manually? >>>>>> - What do we do with Confluence? >>>>>> >>>>>> Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if >>>>>> you >>>>>> still prefer the second option, could you please address the points >>>>>> above? >>>>>> I don't think it can be treated as an actual suggestion until we cover >>>>>> these details. >>>>>> >>>>>> 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. >>>>>> >>>>>> -Val >>>>>> >>>>>> On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko < >>>>>> valentin.kuliche...@gmail.com> wrote: >>>>>> >>>>>>> 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] >>>>>>> >>>>>> https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E >>>>>>> >>>>>>> -Val >>>>>>> >>>>>>> On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov <mr.wei...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>>> 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 <vololo...@gmail.com> 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 14:57 GMT+03:00, Petr Ivanov <mr.wei...@gmail.com>: >>>>>>>>>> How will not they clash if version is based only on date? >>>>>>>>>> >>>>>>>>>>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin <vololo...@gmail.com> >>>>>> 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 <mr.wei...@gmail.com>: >>>>>>>>>>>> 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 <saikat.mai...@gmail.com> >>>>>>>>>>>>> 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 <dma...@apache.org> >>>>>>>>>>>>>> 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 < >>>>>> dma...@apache.org> >>>>>>>>>>>>>> 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 < >>>>>>>> mmu...@apache.org> >>>>>>>>>>>>>>>>> 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<new-gen abrv>" and versioning started from zero. >>>>>>>> However, >>>>>>>>>>>>>> both >>>>>>>>>>>>>>>>>> of Ignite's can easily co-exist. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, 21 Sept 2021 at 22:13, Valentin Kulichenko >>>>>>>>>>>>>>>>>> <valentin.kuliche...@gmail.com> 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. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Folks, quite frankly, this discussion seems >>>>>> counterproductive >>>>>>>> at >>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>> point. Are there any particular suggestions? If so, let's >>>>>>>> discuss >>>>>>>>>>>>>> them. >>>>>>>>>>>>>>>>>> Otherwise, let's just do some coding - isn't that why we are >>>>>>>> all >>>>>>>>>>>>>> here? >>>>>>>>>>>>>>> :) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -Val >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Sep 21, 2021 at 9:52 PM Ilya Kasnacheev < >>>>>>>>>>>>>>>>>> ilya.kasnach...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hello! >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I concur with Nikolay. Maybe Ignite 3 should be called >>>>>>>> "Ignite >>>>>>>>>>>>>> <some >>>>>>>>>>>>>>>>>> adverb>" because it is a product with a different focus and >>>>>>>> values >>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>> has no plans to cover the entirety of Ignite's features. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Ilya Kasnacheev >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> вт, 21 сент. 2021 г. в 17:56, Nikolay Izhikov < >>>>>>>>>>>>>> nizhi...@apache.org >>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hello, Ignite PMC. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Is there any reason to keep calling Ignite3 as "Ignite"? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> It seems to me that from the very beginning Ignite3 is a >>>>>> new >>>>>>>>>>>>>>>>>> database engine built on completely new architecture. >>>>>>>>>>>>>>>>>>>>> Ignite2 and Ignite3 has nothing similar except the name. >>>>>>>> All is >>>>>>>>>>>>>>>>>> different >>>>>>>>>>>>>>>>>>>>> - source code. >>>>>>>>>>>>>>>>>>>>> - repository. >>>>>>>>>>>>>>>>>>>>> - features. >>>>>>>>>>>>>>>>>>>>> - API. >>>>>>>>>>>>>>>>>>>>> - road map. >>>>>>>>>>>>>>>>>>>>> - contributors. >>>>>>>>>>>>>>>>>>>>> - contribution rules. >>>>>>>>>>>>>>>>>>>>> - release cycle. >>>>>>>>>>>>>>>>>>>>> *** you are here *** >>>>>>>>>>>>>>>>>>>>> - jira >>>>>>>>>>>>>>>>>>>>> - confluence >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Should we accept the fact that thing we calling as >>>>>>>> "Ignite3" is >>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>> another project? >>>>>>>>>>>>>>>>>>>>> Can you, please, share your vision on how Ignite and >>>>>> Ignite3 >>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>> coexists? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> вт, 21 сент. 2021 г. в 17:13, Dmitry Pavlov < >>>>>>>> dpav...@apache.org >>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>> valentin.kuliche...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>>>>>> valentin.kuliche...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>> mr.wei...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> +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 < >>>>>>>>>>>>>>>>>> alexpolovt...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +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 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 "ignite-3" label for 3.x >>>>>>>>>>>>>> tickets, >>>>>>>>>>>>>>>>>> but this >>>>>>>>>>>>>>>>>>>>>>>>> approach >>>>>>>>>>>>>>>>>>>>>>>>>>> is fragile. If someone forgets to add the label to a >>>>>>>> new >>>>>>>>>>>>>>>>>> ticket, it's >>>>>>>>>>>>>>>>>>>>>>>>>>> likely to be lost. We need a better separation. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> All the above is true for Wiki as well - we use a >>>>>>>> single >>>>>>>>>>>>>>>>>> Confluence >>>>>>>>>>>>>>>>>>>>>>>>> space. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I suggest creating a new Jira project and a new >>>>>>>>>>>>>> Confluence >>>>>>>>>>>>>>>>>> space for >>>>>>>>>>>>>>>>>>>>>>>>> Ignite >>>>>>>>>>>>>>>>>>>>>>>>>>> 3 and moving all the relevant tickets and pages >>>>>> there. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Any thoughts or objections? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> -Val >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>> With regards, >>>>>>>>>>>>>>>>>>>>>>>>>> Aleksandr Polovtcev >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Ivan Pavlukhin >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Ivan Pavlukhin >>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> >
