You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2019/04/24 19:31:25 UTC
[vote] Win32 Decision Point
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.
Re: [vote] Win32 Decision Point
Posted by Branko Čibej <br...@apache.org>.
On 24.04.2019 21:31, William A Rowe Jr 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.
It has been rather more than 10 days but in case it helps the sampling:
+1 to drop 8-bit/ANSI on Windows.
-- Brane
Re: [vote] Win32 Decision Point
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Apr 25, 2019 at 2:59 AM Ivan Zhakov <iv...@visualsvn.com> wrote:
> [X] Please drop 8-bit and focus only on utf-8 resource names on Win32.
>
> The only problem I see that it would harder to backport fixes to
> stable branches. What about release apr 1.8 without ANSI logic?
>
That isn't possible by my reading of our version contract. Yes, backports
would require some additional adjustments in the existing ANSI code,
but the of changes to that code is the future should be approximately nil.
I don't see us shipping a 1.8, if we proceed on course to ship a 2.0 some
time in the near future. Our feature-set is somewhat complete as things
stand now.
Re: [vote] Win32 Decision Point
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, 24 Apr 2019 at 22:31, 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.
>
>
[X] Please drop 8-bit and focus only on utf-8 resource names on Win32.
The only problem I see that it would harder to backport fixes to
stable branches. What about release apr 1.8 without ANSI logic?
--
Ivan Zhakov
[results] [vote] Win32 Decision Point
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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.
>
>
>
Re: [vote] Win32 Decision Point
Posted by Ruediger Pluem <rp...@apache.org>.
On 04/24/2019 09:31 PM, William A Rowe Jr 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
>
> [ X ] 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.
>
>
Regards
Rüdiger
Re: [vote] Win32 Decision Point
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Apr 24, 2019 at 9:31 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Committers and community both, please choose one below,
[X] Please drop 8-bit and focus only on utf-8 resource names on Win32.
Re: [vote] Win32 Decision Point
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Apr 24, 2019, 14:31 William A Rowe Jr <wr...@rowe-clan.net> wrote:
>...
>
>
> [X] Please drop 8-bit and focus only on utf-8 resource names on Win32.
>
It is a very good breaking change for 2.0. Leave that stuff behind. Devs
who need it can stick to 1.x or choose another solution.
Cheers,
-g