installing-solidity.rst: Update information about prerelases

Author: cameel

docs/installing-solidity.rst

@@ -14,13 +14,12 @@ addition, patch-level releases with major release 0 (i.e. 0.x.y) will not
 contain breaking changes. That means code that compiles with version 0.x.y
 can be expected to compile with 0.x.z where z > y.
 
-In addition to releases, we provide **nightly development builds** to make
-it easy for developers to try out upcoming features and
-provide early feedback. Note, however, that while the nightly builds are usually
-very stable, they contain bleeding-edge code from the development branch and are
-not guaranteed to be always working. Despite our best efforts, they might
-contain undocumented and/or broken changes that will not become a part of an
-actual release. They are not meant for production use.
+In addition to releases, we provide **prereleases** and **nightly development builds** to make it
+easy for developers to try out upcoming features and provide early feedback.
+Note that such builds contain bleeding-edge code from the development branch and are not guaranteed
+to be of the same quality as full releases.
+Despite our best efforts, they might contain undocumented and/or broken changes that will not
+become a part of an actual release. They are not meant for production use.
 
 When deploying contracts, you should use the latest released version of Solidity. This
 is because breaking changes, as well as new features and bug fixes are introduced regularly.
@@ -544,7 +543,7 @@ The Version String in Detail
 The Solidity version string contains four parts:
 
 - the version number
-- pre-release tag, usually set to ``develop.YYYY.MM.DD`` or ``nightly.YYYY.MM.DD``
+- pre-release tag, usually set to ``develop.YYYY.MM.DD``, ``pre.N`` or ``nightly.YYYY.MM.DD``
 - commit in the format of ``commit.GITHASH``
 - platform, which has an arbitrary number of items, containing details about the platform and compiler
 
@@ -553,24 +552,26 @@ If there are local modifications, the commit will be postfixed with ``.mod``.
 These parts are combined as required by SemVer, where the Solidity pre-release tag equals to the SemVer pre-release
 and the Solidity commit and platform combined make up the SemVer build metadata.
 
-A release example: ``0.4.8+commit.60cc1668.Emscripten.clang``.
+Examples:
 
-A pre-release example: ``0.4.9-nightly.2017.1.17+commit.6ecb4aa3.Emscripten.clang``
+- release: ``0.4.8+commit.60cc1668.Emscripten.clang``
+- pre-release: ``0.4.9-pre.3+commit.fb60450bc.Emscripten.clang``
+- nightly build: ``0.4.9-nightly.2017.1.17+commit.6ecb4aa3.Emscripten.clang``
 
 Important Information About Versioning
 ======================================
 
 After a release is made, the patch version level is bumped, because we assume that only
 patch level changes follow. When changes are merged, the version should be bumped according
 to SemVer and the severity of the change. Finally, a release is always made with the version
-of the current nightly build, but without the ``prerelease`` specifier.
+of the current build, but without the ``prerelease`` specifier.
 
 Example:
 
 1. The 0.4.0 release is made.
-2. The nightly build has a version of 0.4.1 from now on.
+2. Nightly builds and preerelases have a version of 0.4.1 from now on.
 3. Non-breaking changes are introduced --> no change in version.
 4. A breaking change is introduced --> version is bumped to 0.5.0.
 5. The 0.5.0 release is made.
 
-This behavior works well with the  :ref:`version pragma <version_pragma>`.
+This behavior works well with the :ref:`version pragma <version_pragma>`.