1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
|
---
title: "imag 0.9.0"
slug: "imag-0-9-0"
date: "2018-11-10T11:10:09"
tags: [ "linux", "open source", "programming", "rust", "software", "tools", "imag" ]
---
<!-- more -->
# 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](https://github.com/Aaronepower/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](http://git.imag-pim.org/imag/tree/doc/src/09020-changelog.md).
* 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](https://git.imag-pim.org/imag/).
# 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!
1. 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`.
1. 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! :-)
|
