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 | catautomatically prints the output ofimag idson 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 withfzf:imag ids | fzf -m | imag tag add "foobar". - imag now uses
failurefor 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.
- The most important bit: This is only my workflow, things do not change for contributors!
- 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. - We tried to use
git notesfor 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 withgit log --merges --first-parent <latest-release>..masterand the minor changes and fixes withgit 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! :-)