As this vote has run 4 weeks, and has 7 votes in favor (including mine),
none opposed, announcing that;
Please drop 8-bit and focus only on utf-8 resource names on Win32.
is now the official policy for APR 2.0 branch. Others are welcome to help
detangle and eliminate the ANSI win32 code paths in these coming weeks.
On Wed, Apr 24, 2019 at 2:31 PM William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> Some 17 years later we are at a crossroads, because the win32 code
> is somewhat illegible and harder to maintain due to the ANSI-vs-UTF8,
> Win9x-vs-NT code paths.
>
> NT won. The only remaining question is how many apr consumers are
> leveraging ANSI-specific builds for local code page semantics, vs how
> many are willing to treat all system resources as utf-8 names, and for
> ANSI, willing to live on the 1.x branch in perpetuity? These are builds
> that explicitly toggle ANSI in spite of whatever OS the binary runs on.
>
> So the vote is pretty simple, I propose to strip all ANSI 8-bit logic from
> the apr (2.0) trunk/ and leave only the utf8->wide char logic remaining.
> Committers and community both, please choose one below,
>
> [ ] Please retain the ANSI logic in APR 2.0 on Win32
>
> [ ] Please drop 8-bit and focus only on utf-8 resource names on Win32.
>
> Will leave this question open a full 10 days to get the widest sampling
> of opinions.
>
>
>
