apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)
Date Sat, 24 Dec 2016 07:32:59 GMT
On 22 December 2016 at 20:21, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> On Thu, Dec 22, 2016 at 3:13 AM, Steffen <info@apachelounge.com> wrote:
>> Below is stated:  .. to make Windows Vista/Server 2008 minimum
>> supported...
>> But.. Windows Embedded POSReady 2009 (It is basically XP SP 3) has updates
>> till May 2019.
> That one doesn't matter to us, any embedded software vendor can continue to
> patch APR 1.x forever if they like. We have no reason to support this as a
> volunteer-driven charitable software project.
> Just to summarize MS dates;
> * Windows XP was EOL Apr '09, entirely out of support Apr '14
> * Windows 8 was EOL Oct '12, entirely out of support Jan '16
> * Windows Vista is EOL since Apr '14, Extended support ends Apr '17
> * Windows 8.1 EOL Jan '18, Extended ending Jan '23
> * Server 2003 was EOL Jul '10, entirely out of support July '15.
> * Server 2008 is EOL since Jan '15, Extended support ends Jan '20
> * Server 2012 is supported EOL Jan '18, Extended ending Jan '23
> * Server 2016 is supported
> * CE 6.0/Embedded 8.1/Embedded 6.5 EOL Jun '18/Jun '19/Jan '20
>   AIUI there is no 'Windows' thing replacing them in this space?
> The concept behind extended support is *not* provisioning brand new
> software, there is no new IIS available to already beyond EOL versions of
> Windows during their extended support period. Extended support is the
> hobble-along period for commercial users who aren't in a position to migrate
> software. In other words, not targets for any enhancements.
As far I understand MS provides security fixes for all customers when
OS in extended support state. They just stop providing bug fixes for
ordinary customers.

> From an APR 1.x perspective, we should keep alive any functionality that
> exists today, and retire functionality we don't want as of APR 2.0. I see us
> offering some security and bug fix patches to APR 1.x for quite a while
> after the release of APR 2.0. I'd simply expect new APR 1.next minor
> releases to fall off in favor of emphasizing APR 2.0 and encouraging rapid
> adoption.
> For APR 2.0 perspective, that means ending everything other than Windows
> Server 2016, Windows Server 2012, Windows 10 and Windows 8.1 support.
> It is debatable whether we should actively support Server 2008 with the next
> major version of APR; if it doesn't hurt us to support it, fine. But if
> there are 2008 API quirks that make this impractical, we should avoid
> explicitly targeting it in this next major version. Even if we had APR 2.0
> ready in January, Vista would be off the radar by April anyways. Why would
> anyone be doing new deployment to Vista? That would be foolish.
Sure, Vista usage is declining, but Windows Server 2008 R2 is actively
used in production. It's standard option in many virtual hosting
providers and there are still reasons to use WS 2008 R2: it's very
stable and proven.

> What I'd like us to consider is to rip out all FooFnA() ASCII calls, and
> shift entirely to the Unicode mapping, [..]
I'm +1 to move APR to Unicode only and remove FooFnA() calls.

> perhaps with some support of
> alternate operating charsets for the non-httpd consumer. Would like to hear
> of folks deliberately building the ANSI flavor of APR on modern OS's and see
> if we can address any concerns.

Ivan Zhakov

View raw message