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://issues.apache.org/jira/browse/IGNITE-13751 > > 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://github.com/apache/ignite-3 > > [2] https://ci.ignite.apache.org/project/ignite3 > > [3] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-DevelopmentProcess > > > > -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 >
