Hi, for SAP it's the same - we currently build everything with VS2017. But bumping to VS2019 and leaving VS2017 behind in head would be fine.
Best regards Christoph > -----Original Message----- > From: build-dev <build-dev-r...@openjdk.org> On Behalf Of Aleksey Shipilev > Sent: Dienstag, 30. August 2022 18:52 > To: Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com>; build- > d...@openjdk.org > Subject: Re: Proposal: drop support for VS2017 in mainline > > On 8/30/22 17:14, Magnus Ihse Bursie wrote: > > I think the time has come for us to drop support for VS2017. Some > > arguments for this: > > > > * VS2017 was moved to "Mainstream End Date" by Microsoft in April, > > 2022 [1] > > Yes, and the Extended End Date is in 2027, so it is not completely dead. Or, > it > has the similar level of freshness and support timeline as JDK 8 :) > > > * VS2017 do not support C11 properly, which makes the fix for > > JDK-8292008 non-ideal [2] > > > > * VS2017 do not support the new conformant preprocessor, which will > > likewise make JDK-8247283 only half-fixed [3] > > > > * VS2017 required us to do ugly workarounds like JDK-8286459, which > > likely should be reverted once we get rid of it [4] > > > > Is anyone tied to VS2017 and would reject a PR that removes support > > for VS2017, leaving only VS2019 and VS2022? > > Personally, for builds.shipilev.net, I gave up building with VS2017 back in > 2020, > and switched to > VS2019 for almost everything. I think the only VS2017 builds are JDK 8u. MSVS > is a funky toolchain, and older MSVS is doubly so. > > But here in Red Hat, we are building Windows binaries for all JDKs with > VS2017, which means dropping support would break our mainline builds, at > least for a while. However, we mostly care about LTS-es, and the next one is > relatively later, so there is plenty of time to catch up. > > So... good riddance? > > -- > Thanks, > -Aleksey
