aboutsummaryrefslogtreecommitdiff
path: root/documentation/building.md
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/building.md')
-rw-r--r--documentation/building.md8
1 files changed, 7 insertions, 1 deletions
diff --git a/documentation/building.md b/documentation/building.md
index 54dace6..bd3eff0 100644
--- a/documentation/building.md
+++ b/documentation/building.md
@@ -18,4 +18,10 @@ The native binaries produced in the previous step may be bundled in a "fat" jar
Note: an important feature of fat jars is to include binaries for several platforms. To copy binaries compiled on other platforms to the fat jar, place them in a subfolder of 'flow-native-sbt/lib_native'. The subfolder should have the name `$(os.name)-$(os.arch)`, where `os.name` and `os.arch` are the java system properties of the respective platforms.
# Note about versioning
-When building and locally publishing projects, the usual convention is to append "-SNAPSHOT" to the version string. This practice however breaks version identification and badly hurts git (bisecting becomes a nightmare). Therefore, to identify a build artifact with a specific commit in the repository, a sha1 hash is appended to the version instead. When publishing a new release, this hash may be ommited by setting the java system property "release=true", simply by running sbt -Drelease=true.
+When building and locally publishing projects, the usual convention is to append "-SNAPSHOT" to the version string. This practice however breaks version identification and badly hurts git (bisecting becomes a nightmare). Therefore, to identify a build artifact with a specific commit in the repository, a sha1 hash is appended to the version instead. When publishing a new release, this hash may be ommited by setting the java system property "release=true", simply by running `sbt -Drelease=true`.
+
+A second versioning quirk to be aware of is when building native sources. In this case, the project and package versions follow a sematic pattern: `M.m.p`, where
+ - `M` is the major version, representing backwards incompatible changes
+ - `m` is the minor version, indicating backwards compatible changes such as new feature additions
+ - `p` is the patch number, representing internal modifications such as bug-fixes
+Usually (following most linux distribution's conventions), shared libraries produced by a project `name` of version `M.m.p` are named `libname.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.3.1.2` becomes `libflow3.0.1.2`.