> Any particular reason why this should be 10.0 and not 9.0 for example? (is due to an incoming feature of note?)
No. I only said 10.0 because Neal's tactical suggestion earlier in this thread would mean that 10.0 would be the last build that had C++11 support. If we choose not to follow that suggestion and want to switch sooner I will not hold that up. On Wed, Aug 17, 2022 at 4:47 PM Sutou Kouhei <k...@clear-code.com> wrote: > > 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? > >> > >>
