Hi, > Here's a tactical suggestion: for 10.0, we could upgrade all* of our > packaging and CI jobs to build with C++17, but not add code that cannot > compile on C++11 (hence the *, we will need to maintain at least one C++11 > CI job to assure that). Then, assuming there are no adverse consequences, > we can start upgrading the codebase to C++17, and 11.0 would be the first > release that can't build on C++11.
How can we evaluate that our official packages built with C++17 don't have any problems? Should we wait for bug reports from users and downstreams? They may not report C++17 related problems so quickly because they may not upgrade our official packages soon. I think that we don't need to do this because we may not be able to find more problems quickly. If we can't get reports quickly, we can't determine we can drop support for C++11 by the next release. (Most of problems will be found by our CI before we release a new version.) If users and downstreams have problems with Apache Arrow C++ that requires C++17, they will still use old Apache Arrow C++ that requires C++11 because they can't use our official packages that are built with C++17. They will update their codebase and required Apache Arrow C++ whenever they want. Thanks, -- kou In <caocv4hguwmvbptuzubrvz4_0sflbr2gjyh+xehza6y0pjkl...@mail.gmail.com> "Re: DISCUSS: [C++] Switch to C++17" on Wed, 17 Aug 2022 08:45:34 -0500, Neal Richardson <neal.p.richard...@gmail.com> wrote: > I have no opinion about the benefits of upgrading to C++17. From the R > perspective, there are a handful of packages on CRAN that require C++14 or > C++17. Last year, when I asked other R package maintainers why they hadn't > upgraded to newer C++ standards, the reasoning was that because many > packages try to support the 5 last versions of R, the Windows 3.6 issue is > still limiting, at least if you hope to be a package that others depend on. > But I don't think this is an argument to prevent us from upgrading: R > package developers have been more likely to take on `arrow` as an optional > dependency, if at all, given the size/complexity of the build. > > Here's a tactical suggestion: for 10.0, we could upgrade all* of our > packaging and CI jobs to build with C++17, but not add code that cannot > compile on C++11 (hence the *, we will need to maintain at least one C++11 > CI job to assure that). Then, assuming there are no adverse consequences, > we can start upgrading the codebase to C++17, and 11.0 would be the first > release that can't build on C++11. > > Neal > > On Wed, Aug 17, 2022 at 3:56 AM Antoine Pitrou <anto...@python.org> wrote: > >> >> Le 17/08/2022 à 10:48, Jacob Wujciak a écrit : >> > I am generally in favour of this proposal but would like to mention that >> we >> > have to be able to build on MacOS 10.13 for the R package due to CRAN >> using >> > it. >> > The CRAN builder comes with: >> > Apple LLVM version 10.0.0 (clang-1000.10.44.4); GNU Fortran (GCC) 8.2.0 >> >> Well, I can't say for sure, but according to this StackOverflow post it >> would probably be ok: >> https://stackoverflow.com/a/54030282 >> >> Do we have CI for that macOS platform? >> Do you know which XCode version that Apple LLVM version corresponds to? >> >>
