Another 14 days vanished quickly as hell. Despite my one-week trip to the Dolomite Alps, I got a hell lot of things done.
Read it up here, in the 16th iteration on whats coming up in imag, the personal information management suite for the commandline
I published a crate
crates.io to claim the name
"imag" - it doesn’t contain anything by now - I
only created it to claim the name and therefor is published in version 0.0.0.
As version 0.2.0 should be published within
this year, this will soon change. I do not yet have any ideas how to publish a
multi-crate project on crates.io, though.
(If you wonder why I jump from 0.0.0 to 0.2.0 - I already had a really early release of imag, 0.1.0, which had some minimal functionality. After that, I started a big rewrite and rewrote the complete codebase, because the initial foundations and core infrastructure was just not well done.)
We also had a small contribution from Julian Ganz, thank you very much!
PRs merged/closed in the last 14 days
Here are the closed PRs from the last 14 days. The range also includes some PRs
that did not yet hit the master branch, as they are from another long-running PR
which introduces some tests for
libimagstore (and fixes for bugs from that
486 - finally! Git support! This PR merged the initial git hook support, so the store is now git version controlled. While this is fundamental git support (and was a rather long-running PR), more PRs will come and add additional features. The following PRs were involved in this PR:
730 introduced matrix builds with travis, to have faster build times.
734 introduced more Makefile targets, so one can execute tests via the makefile now.
756 introduced an option in the configuration file to disable git hooks.
757 reverted a feature from the initial git hook support which was broken.
758 fixed that git created empty commits if no change was made to the contents of the store.
PRs opened in the last 14 days and not yet closed
Some PRs from the last 14 days are not yet closed:
- 759 introduces a new feature so that the commit for a change in the store is made when the store is closed, that leads to less commit noise in the repository.
Issues opened and already closed
We did not open that much issues in the last 14 days, but anyways some are already closed:
What’s coming up in the future?
Issues opened and not yet closed
Lets have a look at the issues we opened and did not close in the last 14 days, we clearly want to close them in the next 14 days:
Well… I have about two weeks left until my semester starts again, so two more weeks to get some stuff done. After that, I guess, development will slow down a bit. Hopefully not much, but enough so I can get good grades in my masters degree.
I’m almost done with the 0.2.0 milestone, so the first release for imag could happen in the next two weeks. We have 83% already done and only soft-required things left, so theoretically we could release in this very moment. Though, I’d like to at least merge the store tests before we do 0.2.0.
Also I’m really thinking about release-strategy and also how to do the release.
Strategy before 1.0.0 would be to simply
git tag a commit on the master branch
and declare that as release. After that I guess I will create version branches,
but as a
1.* release is far away in the future, I don’t think too hard about
The second thing is - how to release this crate on crates.io? I mean…
is a crate with multiple root crates and also multiple crates in one
I already asked on reddit
but I’m not sure the answers fit my problem. All these crates have one
root crate which depends on all other crates in the repository.
not have that - in the
imag repository, each
imag-* directory is a root
crate that depends on other crates from the repository. And the
subdirectory also contains one.
I’m not even sure whether it is actually possible with cargo to publish this setup on crates.io.
Maybe I should ask in the cargo IRC channel on this specific subject.