bump version number, update release date, small python binding fix

CMakeModules/OMPLVersion.cmake

@@ -2,7 +2,7 @@
 set(OMPL_MAJOR_VERSION 1)
 set(OMPL_MINOR_VERSION 4)
 set(OMPL_PATCH_VERSION 0)
-set(OMPL_VERSION "${OMPL_MAJOR_VERSION}.${OMPL_MINOR_VERSION}.${OMPL_PATCH_VERSION}beta")
+set(OMPL_VERSION "${OMPL_MAJOR_VERSION}.${OMPL_MINOR_VERSION}.${OMPL_PATCH_VERSION}")
 
 # increment this when we have ABI changes
 set(OMPL_ABI_VERSION 15)

doc/markdown/releaseNotes.md

 # Release Notes {#releaseNotes}
 
-# OMPL 1.4.0 (????)
+# OMPL 1.4.0 (June 25, 2018)
 
 - There is a new framework for planning with constraints that unifies and generalizes prior proposed algorithms such as CBiRRT2, AtlasRRT and TangentBundle-RRT. The framework decouples the methodology used for computing configurations that satisfy constraints from the high-level planning strategy. This allows the user to use any sampling-based planning algorithm in OMPL with arbitrary geometric constraints. See the [overview](constrainedPlanning.html), [tutorial](constrainedPlanningTutorial.html) and various [demos](group__demos.html) in `ompl/demos/constraint`.
 - Eigen3 is now a required dependency.

py-bindings/generate_bindings.py

@@ -624,6 +624,11 @@ class ompl_geometric_generator_t(code_generator_t):
         # exclude deprecated API function
         self.ompl_ns.free_function('getDefaultPlanner').exclude()
 
+        # Using nullptr as a default value in method arguments causes
+        # problems with Boost.Python.
+        # See https://github.com/boostorg/python/issues/60
+        self.ompl_ns.class_('PathSimplifier').add_declaration_code('#define nullptr NULL\n')
+
         # Py++ seems to get confused by some methods declared in one module
         # that are *not* overridden in a derived class in another module. The
         # Planner class is defined in ompl::base and two of its virtual methods,