Release new versions

README.md

@@ -20,14 +20,15 @@ Supported:
 * Attributes
 * Subgroups
 * Open/Append/Create modes
-* Reading from memory (read only for now)
+* Reading from memory
 * Unlimited dimensions
-* string variables
-* user defined types (variable length, enum, compound, opaque)
+* String variables
+* User defined types (variable length, enum, compound, opaque)
 
 Not (yet) supported:
 
-* some exotic user defined types
+* Nested user defined types
+* Writing using memory-mapped file
 
 All variable data is read into a contiguous buffer, or into an [ndarray](https://github.com/rust-ndarray/rust-ndarray) if the `ndarray` feature is activated.
 
@@ -37,7 +38,9 @@ This crate depends on `libnetcdf`, but a static build from source is also suppor
 
 The crate is built on several platforms using github actions, and is currently known to build form from source on all major platforms (linux, macos, windows (gnu+msvc)), and through the package installers `conda` and `apt`.
 
-### Building without `netcdf-c`
+If during compilation there is an error in building the `hdf5` crate, consider using the `static` feature which will include a compatible version of both `netcdf` and `hdf5`. This is likely to be an issue [upstream](https://github.com/aldanor/hdf5-rust/issues/262).
+
+### Building without `libnetcdf` or building statically
 1. `git clone https://github.com/georust/netcdf`
 2. `git submodule update --init --recursive`
 3. `cargo build --features static`
@@ -50,7 +53,7 @@ Some examples of usage can be found in the [tests/lib.rs](netcdf/tests/lib.rs) f
 
 ## Thread safety
 
-The `netcdf-c` library is not threadsafe. To render a safe interface, a global mutex is used to serialize access to the underlying library. If performance is needed, consider using a non threadsafe version of `hdf5`, so double locking is avoided.
+The `netcdf` crate is thread-safe, although the `netcdf-c` library is not itself threadsafe. To render a safe interface, a global mutex is used to serialize access to the underlying library. Consider using a non threadsafe version of `hdf5` to avoid double locking (performance consideration).
 
 Use of `netcdf-sys` is not thread-safe. Users of this library must take care that calls do not interfere with simultaneous use of e.g. `netcdf`. Using the `hdf5-sys` library could also pose a problem, as this library is used throughout `netCDF-c` and internal state may be disrupted.
 

netcdf-sys/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "netcdf-sys"
-version = "0.5.1"
+version = "0.6.0"
 authors = [
     "Michael Hiley <mhiley@gmail.com>",
     "Magnus Ulimoen <magnusu@met.no>"

netcdf/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "netcdf"
-version = "0.8.3"
+version = "0.9.0"
 authors = [
     "Michael Hiley <mhiley@gmail.com>",
     "Magnus Ulimoen <magnusu@met.no>"
@@ -21,7 +21,7 @@ static = ["netcdf-sys/static"]
 
 [dependencies]
 ndarray = { version = "0.15", optional = true }
-netcdf-sys = { path = "../netcdf-sys", version = "0.5.0" }
+netcdf-sys = { path = "../netcdf-sys", version = "0.6.0" }
 bitflags = "1.2.1"
 
 [dev-dependencies]