stash site changes

2 files changed, 7 insertions, 7 deletions

diff --git a/site/jekyll/documentation/developer.md b/site/jekyll/documentation/developer.md
index 9e55fa9..c09d49b 100644
--- a/site/jekyll/documentation/developer.md
+++ b/site/jekyll/documentation/developer.md
@@ -12,7 +12,7 @@ A complete build of flow involves two parts
 Both steps are independent, their only interaction being a header file generated by the JDK utility `javah` (see `sbt javah` for details), and may therefore be built in any order.
 
 ## Building Scala Sources
-Run `sbt flow-main/packageBin` in the base directory. This simply compiles Scala sources as with any standard sbt project and packages the resulting class files in a jar.
+Run `sbt flow-main/packageBin` in the base directory. This simply compiles Scala sources as with any standard sbt project and packages the resulting class files into a jar.
 
 ## Building Native Sources
 The back-end is managed by CMake and all relevant files are contained in `flow-native/src`.
@@ -28,7 +28,7 @@ Several steps are involved in producing the native library:
 2. Compile
 
     1. Run `make`.
-       *Note: should you encounter an error about a missing "jni.h" file, try setting the JAVA_HOME environment variable to point to base path of your JDK installation.*
+       *Note: should you encounter an error about a missing "jni.h" file, try setting the JAVA_HOME environment variable to point to the base path of your JDK installation.*
 
 3. Install
 
@@ -41,14 +41,14 @@ Several steps are involved in producing the native library:
     - put into a "fat" jar, useful for dependency management with sbt (see next section)
 
 ### Creating a Fat Jar
-The native library produced in the previous step may be bundled into a "fat" jar so that it can be included in SBT projects through its regular dependency mechanisms. In this process, sbt basically acts as a wrapper script around Autotools, calling the native build process and packaging generated libraries. Running `sbt flow-native/packageBin` in the base directory produces the fat jar in `flow-native/target`.
+The native library produced in the previous step may be bundled into a "fat" jar so that it can be included in SBT projects through its regular dependency mechanisms. In this process, sbt basically acts as a wrapper script around CMake, calling the native build process and packaging generated libraries. Running `sbt flow-native/packageBin` produces the fat jar in `flow-native/target`.
 
 Note: an important feature of fat jars is to include native libraries for several platforms. To copy binaries compiled on other platforms to the fat jar, place them in a subfolder of `flow-native/lib_native`. The subfolder should have the name `$(arch)-$(kernel)`, where `arch` and `kernel` are, respectively, the lower-case values returned by `uname -m` and `uname -s`.
 
 ### Note About Versioning
 The project and package versions follow a [semantic](http://semver.org/) pattern: `M.m.p`, where
 
-- `M` is the major version, representing backwards incompatible changes
+- `M` is the major version, representing backwards incompatible changes to the public API
 
 - `m` is the minor version, indicating backwards compatible changes such as new feature additions
 
@@ -57,11 +57,11 @@ The project and package versions follow a [semantic](http://semver.org/) pattern
 Usually (following most Linux distribution's conventions), shared libraries produced by a project `name` of version `M.m.p` are named `libname.so.M.m.p`. However, since when accessing shared libraries through the JVM, only the `name` can be specified and no particular version, the convention adopted by flow is to append `M` to the library name and always keep the major version at zero. E.g. `libflow.so.3.1.2` becomes `libflow3.so.0.1.2`.
 
 # Publishing and Releasing
-The release process managed with the `sbt-release` plugin. See 'project/Release.scala' for a description of the various steps involved.
+The release process is managed with the `sbt-release` plugin. See 'project/Release.scala' for a description of the various steps involved.
 
 Here are some important notes on creating a release:
 
-- During a release, only readily available libraries in `lib_native` are packaged into the fat jar, no local compilation is performed. The rationale behind this is that while native libraries rarely change, they are tied to the version of libc of the compiling system. Since the releases are mostly done on a cutting-edge OS, compiling native libraries locally could break compatibility with older systems.
+- During a release, only readily available libraries in `lib_native` are packaged into the fat jar, no local native compilation is performed. The rationale behind this is that while native libraries rarely change, they are still tied to the version of libc of the compiling system. Since the releases are mostly done on a development machine (cutting-edge OS), compiling native libraries locally could break compatibility with older systems.
 
 - Currently, the release script does not handle uploading the native libraries archive (don't confuse this with the fat jar, which is uploaded). If creating a release that changed the native libraries or added support for more platforms, creating and uploading a new native archive must be done manually.
 
diff --git a/site/jekyll/documentation/index.md b/site/jekyll/documentation/index.md
index 8b9f993..741e59c 100644
--- a/site/jekyll/documentation/index.md
+++ b/site/jekyll/documentation/index.md
@@ -9,7 +9,7 @@ Start by reading the manual and checking out some examples.
   Explains how to get started and how to use all features. Definitive guide to using flow.
 
 - <i class="fa fa-book"></i> [Examples](https://github.com/jodersky/flow/tree/master/flow-samples)
-  See some very simple, working demo applications.
+  See some very simple, demo applications.
 
 - <i class="fa fa-code"></i> [API documentation]({{site.url}}/latest/api#com.github.jodersky.flow.Serial$)
   Browse flow's API.