Hi Dmitriy, I don't think there is any reason for concern at this point. The community agreed on the scope of the changes for 3.0 - it is described on Wiki. The scope is quite big, so it is clear that 2.x and 3.x will have to exist in parallel for a significant amount of time, so we need a place where we can merge the code for 3.x. Thus, I've created this new repo. We already have multiple IEPs, as well as several contributors who are actively involved in development. Some of the first PRs were merged today.
I didn't hear any objections since the repo was created. -Val On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov <dpav...@apache.org> wrote: > Folks, I'm a little bit concerned about the simultaneous > - existence of the repo https://github.com/apache/ignite-3 and PRs for > that > repo > - and a couple of downvotes from PMC members. > > Is it all fine here? Was there any vote /discussion where it was discussed > and consensus approved? What is the status of the ignite-3 repo? > > вт, 15 дек. 2020 г. в 17:30, Carbone, Adam <adam.carb...@bottomline.com>: > > > I don't believe Java 7 was LTS, and I hope that others will have upgraded > > long before that. If that is the release timeframe for 3.0, then I > suppose > > that would makes sense, I would still doubt that people would be going > > newer than java 11, just my opinion of what I'm seeing. > > > > Regards > > ~adam > > > > Adam Carbone | Director of Innovation – Intelligent Platform Team | > > Bottomline Technologies > > Office: 603-501-6446 | Mobile: 603-570-8418 > > www.bottomline.com > > > > > > > > On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <ilya.kasnach...@gmail.com> > > wrote: > > > > Hello! > > > > I guess Ignite 3.0 will be ready for production use somewhere in > 2022, > > realistically. By that time, Java 8 will be long enough out of > support > > so > > that most companies will actually forbid its use, WRT vulnerabilities > > et > > all. > > > > After all we have managed to upgrade from Java 7 to Java 8 and only > > got a > > minor amount of complaints. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пн, 14 дек. 2020 г. в 19:06, Carbone, Adam < > > adam.carb...@bottomline.com>: > > > > > So just one bit to consider... Are there features that you need to > > use in > > > these newer versions of java? Or are we just updating to stay > > current? The > > > reason I ask is that there are still lots of people in an > enterprise > > space > > > that are beholden to having to support legacy JAVAEE supported > > applications > > > on Websphere, Weblogic, Redhat, etc... and the organizations that > > use those > > > platforms are slow to move... Most of them are still on Java8 > > > > > > So as a platform I think a strong consideration needs to be towards > > having > > > the broadest possible support profile until it becomes an > impediment > > to > > > doing things that the platform needs. So far I haven't seen huge > > things in > > > the newer versions of java that are must haves ( a few exceptions > are > > > things that would be really nice to take advantage of ). > > > > > > I think that apache commons has taken the right approach by staying > > on > > > java 8 giving the largest possible user base. > > > > > > Even standardizing on java 11 would have to make us reconsider > > Ignite as > > > the platform we are using, we are not so invested in it as of now, > > even > > > though we have big plans to leverage it. Just because we aren't > sure > > when > > > we are going to be able to upgrade from java8. It has support > > through 2022, > > > so I imagine that is when we will be discussing that. > > > > > > Regards > > > > > > ~Adam > > > > > > Adam Carbone | Director of Innovation – Intelligent Platform Team | > > > Bottomline Technologies > > > Office: 603-501-6446 | Mobile: 603-570-8418 > > > www.bottomline.com > > > > > > > > > > > > On 11/24/20, 7:38 AM, "Alexey Zinoviev" <zaleslaw....@gmail.com> > > wrote: > > > > > > Java 15 is better, VarHandles, ForeignMemory access and so on. > > > > > > In both cases, I support the Java version 11 and higher for the > > > development! > > > > > > вт, 24 нояб. 2020 г. в 15:21, Andrey Mashenkov < > > > andrey.mashen...@gmail.com>: > > > > > > > Let's add maven plugins for sanity checks at the early > stage. > > > > I've created a ticket for this [1]. > > > > > > > > Also, I've found initial pom.xml has a target version Java 8. > > > > Do we intend to move to Java 11 (or may be next LTS) and drop > > Java 8 > > > in > > > > Ignite 3.0? > > > > > > > > [1] > > > > > > https://urldefense.com/v3/__https://issues.apache.org/jira/browse/IGNITE-13751__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKAO2Ejs8$ > > > > > > > > On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko < > > > > valentin.kuliche...@gmail.com> wrote: > > > > > > > > > Folks, > > > > > > > > > > I went ahead and created the repository [1]. I also > > configured a > > > TeamCity > > > > > project [2] that runs all available JUnit tests on every PR > > > creation or > > > > > update. It also sends the status update to GitHub so that > > it's > > > reflected > > > > in > > > > > the PR itself so that we can do merges directly from > GitHub. > > Basic > > > steps > > > > to > > > > > make a change are described on the Wiki page [3]. > > > > > > > > > > Let me know if you have any questions. > > > > > > > > > > [1] > > > > > > https://urldefense.com/v3/__https://github.com/apache/ignite-3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKIq24lxF$ > > > > > [2] > > > > > > https://urldefense.com/v3/__https://ci.ignite.apache.org/project/ignite3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKFGL_oJx$ > > > > > [3] > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0*ApacheIgnite3.0-DevelopmentProcess__;Kysj!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKNhWzQ0s$ > > > > > > > > > > -Val > > > > > > > > > > On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko < > > > > > valentin.kuliche...@gmail.com> wrote: > > > > > > > > > > > Thanks, guys. It looks like we are much closer to the > > consensus > > > now. I > > > > > > totally on board with the plan, but I would also like to > > address > > > the > > > > > > short-term needs. As I've already mentioned earlier, > there > > are > > > several > > > > > > active IEPs, but we still don't have even a preliminary > > technical > > > > process > > > > > > for working on these IEPs. I believe this might be > > frustrating > > > for the > > > > > > folks who would like to commit code. > > > > > > > > > > > > The scope we agreed on is quite big, and it will surely > > take > > > > significant > > > > > > time to implement all the changes and stabilize them. > > Therefore, > > > it's > > > > > clear > > > > > > to me that we will have to maintain 2.x and 3.x in > > parallel for > > > quite > > > > > some > > > > > > time - this needs to be addressed somehow. I'm convinced > > that > > > having a > > > > > > separate repo is the ONLY way to do that, and so far, I > > haven't > > > heard > > > > any > > > > > > clear alternatives or reasons why we shouldn't do this. > > > > > > > > > > > > That said, I'm inclined to proceed with this in the next > > few > > > days - I > > > > > will > > > > > > create a repo and describe the process (which we, of > > course, can > > > > discuss > > > > > > and modify going forward). Let's, at the very least, try > > and see > > > where > > > > it > > > > > > leads us. > > > > > > > > > > > > If someone has any concrete alternative options on how to > > we can > > > > maintain > > > > > > two major versions in parallel, let's have another voice > > > discussion > > > > this > > > > > > Friday. If we do the meeting, we should set it up with a > > clear > > > goal to > > > > > make > > > > > > a decision. Please let me know if there is interest in > > this. > > > > > > > > > > > > -Val > > > > > > > > > > > > On Mon, Nov 16, 2020 at 6:31 AM Alexey Goncharuk < > > > > > > alexey.goncha...@gmail.com> wrote: > > > > > > > > > > > >> Good, > > > > > >> > > > > > >> I think we have an intermediate agreement on the scope > and > > > > significance > > > > > of > > > > > >> the changes we want to make. I suggest creating separate > > > discussion > > > > > >> streams > > > > > >> and calls for each of the suggested topics so that: > > > > > >> > > > > > >> - It is clear for the community what is the > motivation > > of the > > > > stream > > > > > >> (this includes both functional targets and technical > > debt > > > issues > > > > > >> pointed > > > > > >> out by Sergey) > > > > > >> - Who is planning to take an active part in each of > the > > > streams > > > > (i.e. > > > > > >> the 'design committee', as Sergey suggested) > > > > > >> - What are the intermediate and final goals for each > > of the > > > streams > > > > > >> - What are the cross-stream interactions and how we > > > integrate them > > > > > >> - How each of the streams will be integrated with the > > current > > > > > codebase > > > > > >> based on the above (here is where we will see whether > > > drop-in or > > > > > >> incremental approaches make more sense) > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Andrey V. Mashenkov > > > > > > > > > > > > > > >
