email rss
imag 0.3.0
Aug 25, 2017
6 minutes read

I did it! Just hours ago I released imag in version 0.3.0.

First of all (like with the 0.2.0 release): This is not production-ready software. Use at your own risk! This is a release for people to notice that some things work and one could start to play around with it. Do not trust imag with your personal data if you do not have backups. There are bugs. This is not perfect. This is alpha quality or pre-alpha quality software!

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before being productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

How the release was done

What did I do to get to the release? Well, not that much. I checked out the master branch and created a v0.3.0 branch on it, then started to fix things up for the release.

Then I manually published libimagutil and libimagerror because they do not depend on other imag crates themselves. After that I cargo published all crates one by one until all crates were published, fixing errors while doing so and when all crates were published I tagged the release and pushed out my code to all remote repositories.

The .imag-documentation crate was not published this time, I even plan removing this crate from the imag codebase as there’s no purpose on keeping it right now.

I removed the v0.3.0 branch and created an annotated tag for the release.

Changelog / What’s in there

In this release we have merged 130 branches, from pull request number 821 to 1010, some still pending though. The release itself is clearly too big and I really want to make the next release smaller and maybe even within this year. But I won’t commit to that too hard, because we all know how little time I will have compared to what amount of time I want to invest into the project.

So, a full list of merges goes here. The pull request number is linked to the github issue, while the hash is linked to the commit in our git web interface.

What we have by now:

  • imag - The imag binary itself. The purpose of this is to be able to call imag view instead of imag-view.
  • imag-bookmark - A tool to keep and organize your bookmarks
  • imag-counter - A simple counter tool. Create, delete, increment and decrement counters
  • imag-diary - A diary
  • imag-link - Link imag entries with other imag entries
  • imag-mail - This is not implemented at all and shouldn’t even be usable right now.
  • imag-notes - Create notes
  • imag-ref - Reference files on your Filesystem with imag
  • imag-store - Core plumbing tool. Do not use at all if you do not know what this is for.
  • imag-tag - Tag imag entries
  • imag-todo - Todo management with imag, using taskwarrior as backend. This is not a replacement for taskwarrior, but can be used to create entries in the imag store for each taskwarrior task and then these entries can be linked with imag-link.
  • imag-view - View entries from the imag store

Clearly this is not everything. We have a huge number of libraries which work under the hood of these executables, but users might not care about this.

What had to be fixed for the release

Some changes had to be done before the release could be made, unfortunately. This includes the path-dependency specifications to be rewritten, but unfortunately also more.

The path dependencies had to be rewritten because we develop the imag codebase with each crate depending on other crates in the repository (besides external crates). And because we do not want to release imag crates all the time, we do this by depending on a path:

path = "../libimagstore"

for example. Because we want to depend on actual “” when publishing, we had to rewrite all path specifications to:

libimagstore = "0.3.0"

(for example).

Because we are then only possible to publish crates which have no dependencies or dependencies which are already on, we had to publish the imag crates in a specific order:

./bin (the imag binary)

And because some of these could not be published right away (see the order, first I published the “core” crates which do not depend on any other crate in the list, then the store, then the libimagentry* crates, after that the libimag* crates and the binaries as the last step, finishing with the imag binary itself).

Besides the path dependency specification rewrite commit, we have a bunch of other commits in the branch from master..v0.3.0:

The last commit is also the one that holds the v0.3.0 tag and marks the release of the imag core distribution therefore.

What’s coming

Well, what’s coming for the next release? The 0.4.0 milestone already exists and there are a lot of things already registered in it.

When will I be there? The next version will be there if its ready. Honestly I don’t know. We have a lot of things to tackle and this is growing to be a really huge project, especially for a one-man-show, which it almost is, still.

Can I use imag libraries in my project?


Well, you can, but I do not guarantee any stability or API consistency or something. But if you want, you clearly can use one of the imag libraries (they are on, so why not). Just keep in mind that interfaces will change and things will break and bugs will happen. We are 0.3.0 here, not 1.x.y. Keep that in mind.

That being said… feel free to play around by installing the imag crates (and having backups) and maybe you will be in the git log of the next release?

Back to posts