Added Xcode 10.2 to Travis builds, bumped WIP version, updated readme.

.travis.yml

@@ -36,6 +36,10 @@ matrix:
       env: MATRIX_EVAL="CC=clang && CXX=clang++ && GENERATOR=Xcode"
       osx_image: xcode9.2
 
+    - os: osx
+      env: MATRIX_EVAL="CC=clang && CXX=clang++ && GENERATOR=Xcode"
+      osx_image: xcode10.2
+  
 install:
   - eval "${MATRIX_EVAL}"
   - |

README.md

@@ -401,10 +401,10 @@ and part of the justification for the proposed solution is "we did it so for alm
 But this makes `fs::copy` with `fs::copy_options::create_symlinks` or `fs::copy_options::create_hard_links`
 just a more complicated syntax for the `fs::create_symlink` or `fs::create_hardlink` operation
 and I don't want to believe, that this was the intention of the original writing.
-As there is another issue related to copy, with a different take on the description,
+As there is another issue related to copy, with a different take on the description.
-I keep my version the way I read the description, as it is not contradicting the standard and useful. Let's see
-what final solution the LWG comes up with in the end.
 
+**Note:** With v1.1.2 I decided to integrate a behavior switch for this and make the LWG #2682
+the default.
 
 ## Open Issues
 

include/ghc/filesystem.hpp

@@ -149,7 +149,7 @@
 #define LWG_2937_BEHAVIOUR
 
 // ghc::filesystem version in decimal (major * 10000 + minor * 100 + patch)
-#define GHC_FILESYSTEM_VERSION 10101L
+#define GHC_FILESYSTEM_VERSION 10103L
 
 namespace ghc {
 namespace filesystem {