email rss
imag 0.9.0
Nov 10, 2018
4 minutes read

What’s in there

  • 297 commits
  • 39 merge-commits / 258 non-merge commits
  • 306 files changed
  • 4845 insertions(+), 5334 deletions(-)

Some more statistics about the codebase (thank you, tokei), because why not:

 Language            Files        Lines         Code     Comments       Blanks
 BASH                    8          151           96           17           38
 CSS                     1           27           24            0            3
 Makefile                1          161           97           29           35
 Markdown               99         4814         4814            0            0
 Nix                     2           98           66           11           21
 Rust                  258        33292        21849         6320         5123
 Shell                  14          519          280          157           82
 TOML                   60         3134         2104          422          608
 Total                 443        42196        29330         6956         5910

What changed

This release is rather small in number of changes, but rather big in impact of changes and complexity of the introduced changes. For a complete list of changes, have a look at the CHANGELOG file in the repository.

  • The filesystem backend was optimized so that imag does not keep the handles to the opened files, but reads the files in one go and then drops the filedescriptors. This way it is possible to read a large number of files with imag without running into filedescriptor limits.
  • The Store::entries() function interface was changed and now gives you an iterator which can be optimized to iterate only over subsets of imag entries. This speeds up several operations.
  • imag now uses a uniform IO system where the runtime library automatically detects pipes and handels them accordingly to our standard behaviour. With this, command-chaining (piping like with normal shell commands) is possible, because if imag detects a pipe in the output, it automatically reports “touched” store entries. For example, imag ids | cat automatically prints the output of imag ids on stderr and the “touched entries” to the pipe. These can then be re-used, for example for another imag command or for something else. Example: Tagging some entries, by interactively selecting them with fzf: imag ids | fzf -m | imag tag add "foobar".
  • imag now uses failure for error handling.
  • imag-diagnostics got a progress bar.

Of course there were also a large number of fixes, updates of dependencies and other patches. For a even more detailed list, see the git history.

What’s coming

Lets have a look into the future, what will happen until the next release?

Workflow changes

As we moved away from github, the workflow will now change a bit.

  1. The most important bit: This is only my workflow, things do not change for contributors!
  2. First of all, minor patches and fixups will not be merged “non-fast-forward” anymore. I will push “minor” changes to branches on github (usually the “minor” branch or some “fix-*” branch) to CI-test them, but if they succeed, I will fast-forward merge them into master from now on. This only applies to patches where one patch is the whole change and does not relate to other patches. So feature branches and multi-patch changes will still be merged with --no-ff.
  3. We tried to use git notes for keeping the changelog. Unfortunately, it proofed too clumsy. From 0.9.0 onwards, we will keep the changelog via the merge commit message, so the changelog will be gernerated using a new script which does: List there major changes with git log --merges --first-parent <latest-release>..master and the minor changes and fixes with git log --no-merges --first-parent <latest-release>..master.

What will be in imag 0.10.0

imag 0.10.0 will be a tooling release. imag-calendar and imag-mail will be written and added in imag 0.10.0. libimagentryref has to be reimplemented for that, which makes it another requirement for the release. But that’s it - I’m trying to keep the 0.10.0 release small. Maybe I opt to release it with only one of the tools (imag-calendar/imag-mail), depending on how fast we get there.

When will that be? Well, as I’m back on the road (traveling) until mid-february 2019, the release won’t be this year. It will definitively be next year, … when it is ready! :-)

Back to posts