Proposal: drop support for VS2017 in mainline

[Langer, Christoph]

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-retn at openjdk.org> On Behalf Of Aleksey Shipilev
> Sent: Dienstag, 30. August 2022 18:52
> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; build-
> dev at 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