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
    >     >
    >
    >

Reply via email to