From 3cd760446e00e94120f49d63fb1976db8b42310b Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 13 Sep 2016 12:13:21 +0100 Subject: [PATCH] Split versioning into two sections --- docs/installing-solidity.rst | 34 +++++++++++++++++++--------------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/docs/installing-solidity.rst b/docs/installing-solidity.rst index 42d7bf984..ebb7537be 100644 --- a/docs/installing-solidity.rst +++ b/docs/installing-solidity.rst @@ -12,21 +12,8 @@ Versioning Solidity versions follow `semantic versioning ` and in addition to releases, **nightly development builds** are also made available. The nightly builds are not guaranteed to be working and despite best efforts they might contain undocumented -and/or broken changes. - -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. - -Example: -- 0) the 0.4.0 release is made -- 1) nightly build has a version of 0.4.1 from now on -- 2) non-breaking changes are introduced - no change in version -- 3) a breaking change is introduced - version is bumped to 0.5.0 -- 4) the 0.5.0 release is made - -This behaviour works well with the version pragma. +and/or broken changes. We recommend to use the latest release. Package installers below +will use the latest release. Browser-Solidity ================ @@ -208,3 +195,20 @@ Alternatively, you can build for Windows on the command-line, like so: .. code:: bash cmake --build . --config RelWithDebInfo + +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. + +Example: +- 0) the 0.4.0 release is made +- 1) nightly build has a version of 0.4.1 from now on +- 2) non-breaking changes are introduced - no change in version +- 3) a breaking change is introduced - version is bumped to 0.5.0 +- 4) the 0.5.0 release is made + +This behaviour works well with the version pragma.