0.5.0 release

[aldanor]

So I've been thinking, although the crate is clearly in pre-alpha stage now, it has evolved enough for other folks to be able to contribute, plus it reached a somewhat usable state, with derive proc-macros done and basic dataset reading/loading working.

As such, I'm proposing to merge the current dev branch into master soon and release a 0.3.0a (where "a" underlines the crate's alpha state); motivation:

• People who visit github page wouldn't be thrown off by "last updated: 2.5 years ago" status (there's been over 350 new commits in the dev branches). Most of the traffic is from google, so it would help.
• Would hopefully also attract potential contributors (with master branch showing most recent progress).
• The current version would be cargo-installable without touching git
• hdf5-derive and hdf5-types crate names would be reserved on crates.io, currently they're not so anyone can take them.
• Update the docs (they are in messy state right now and most are missing, but at least the API would be sort-of-browsable).

Things to do:

• Merge in the dataset slice read/write API (although it needs cleanup, more tests, refactoring and non-standard layout support - we'll refactor it later; the API isn't likely to change). (read_slice() / write_slice() methods to permit dataset slice IO #20)
• Merge of the latest work into master; clean up the branches.
• Update the README with a simplest example involving derive macro and dataset reading / writing.
• Update the changelog (going to be lengthy).
• Fix compiletest on Travis so we can finally see some green builds (also they're currently failing on nightly due to Can't install nightly-2019-01-10 rust-lang/rust#57488; also there's an upstream bug in compiletest-rs with the latest nightly on OS X).
• Fix the issue with hbool_t (hbool_t on Windows and accessing HDF5 config header #28); may require rewriting the current build system. (fixed in Rewrite build system, fix hbool_t, remove libhdf5-lib crate #29).
• Make high-level objects cloneable, separate .copy() (Make File cloneable #23) -- this is pretty simple to implement.
• Finish the work on FCPL / FAPL, including various file driver backends and writing tests. (File-access property lists API (+MPI / direct VFD support) #31)
• Resolve the story with potential crate renaming.

[Enet4]

I certainly agree with a new release, for the reasons already mentioned. The features made available here would have enabled me to make a few more of my work tools in Rust. Moreover, if you wish to take the crate name h5, you're still on time to occupy it before someone decides to squat it.

I expect the version to be semver compatible: how about 0.3.0-alpha.0?

[aldanor]

Moreover, if you wish to take the crate name h5, you're still on time to occupy it before someone decides to squat it.

That's the part I'm unclear about -- the top-level crate's name here is "hdf5-rs" (which, in my personal opinion, is good - from discoverability perspective). However the imports are like h5::File (which is good from usability perspective). What happens if someone adds an "h5" crate on crates.io? Should I "squat" it and create an empty one? Not sure how it works.

0.3.0-alpha.0

Sounds good. I think -alpha.1 is more common though.

[Enet4]

My concern about h5 is that hdf5-rs is not a conventional crate name because of the "-rs" suffix (although I undestand why it's there, hdf5 is already taken). And so, at some point I guess you could choose to move the library to use h5 as the root crate.

Sounds good. I think -alpha.1 is more common though.

All good. 👍

[aldanor]

And so, at some point I guess you could choose to move the library to use h5 as the root crate.

Provided it's available :)

My concern about h5 is that hdf5-rs is not a conventional crate name because of the "-rs" suffix (although I undestand why it's there, hdf5 is already taken).

I guess I could try talking to the owner of hdf5 crate - we've briefly chatted in one of the issues on his repo a few years back already re: collab. Not sure he'd agree though (hdf5 and hdf5-sys crates). The hdf5 crate has 0 dependents so it can be simply cargo yanked if everyone agrees to it. The hdf5-sys has 1 dependent (numeric), this could be discussed over. Would having hdf5 as both the crate name (as in cargo install hdf5) and library name (as in hdf5::File) be better than hdf5/h5? hdf5-rs/h5? (it's all hypothetical at this point)

[aldanor]

I have contacted the owner of hdf5 / hdf5-sys crates on crates.io -- please see #25 for details.

[aldanor]

Most of the points on the above todo list have been resolved (including the naming dilemma); the only one that was left has been moved to a separate ticket (#34).

The crate version will have to be bumped all the way to 0.5.0 so that it shadows all versions of the currently available hdf5/hdf5-sys crates on the crates index (even though the old crates will be yanked and will be inaccessible for new projects).

[aldanor]

Ok: https://crates.io/crates/hdf5