I did it! Just hours ago I released imag in version 0.2.0.
Read here why I did that, despite there are few things working and I do not even consider this stable or even stableish.
First of all: 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 beeing 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.2.0 branch on it, then started to fix
things up for the release. That included:
- Moving the dependencies for all crates to “0.2.0”. That means that all
crates in the imag code repository do not depend on other crates from the
imag repository by their path but via crates.io and the “0.2.0” version of
I had to do that to be able to publish these crates.
This change wasn’t done in
master, so we can continue to work on multiple crates at the same time and do not have to
cargo publisheach crate independendently before beeing able to use it in other imag crates.
- I fixed the dependency markup in
imag-store(actually two times) and the version information in
imag-bookmark(in two seperate commits). Why is that? Well… because nobody is perfect. I simply missed them when updating the version strings from “0.1.0” (which is generated by
cargo new) to “0.2.0”.
Then I manually published
libimagerror because they do not
depend on other imag crates themselves.
After that I
cargo published all crates in a loop until all of them were
In the end I
imag crate itself) and
.imag-documentation (the documentation crate which does nothing by itself
and just depends on all other crates for building the documentation).
I removed the
v0.2.0 branch and created an annotated tag for the release.
I released imag 0.2.0 today because there are only few things left in
the milestone for the 0.2.0 release
and all whats left is tagged with
release/optional, saying that these things
are optional for the release (the issues will move to the next milestone, so
they might not be there anymore when you click on this link).
The commit I based the release branch on was more-or-less random. It does not mark any special point in time or something, I just started to branch off of it.
Why releasing if not ready?
Why did I do the release if the software is not ready and nowhere from stable or even stableish?
That answer is pretty easy: To have a point to refer to and to get into a cycle (a release cycle). I’m pretty confident that this version is a point where interested people (read: interested developers and possible contributors) could start playing around with the software. Clearly, bugs are there and things will break. But, as imag is a rather complex piece of software and a large project, I wanted to have a point where people can be notified “Hey, this is working(ish) and you could try it out” so they can jump on the train.
And that’s really what I want. I do not want to develop this monstrous project alone. I want the collaborate on this and hear what people want and need. This project solves my personal problems with PIM, but I’m sure that others will benefit from it as well and therefor community efforts are deeply encouraged by me. Or at least I hope that I do communicate this clear enough.
What’s in there
Do not use imag if you do not have backups. See above for more detailed warning note.
What we have by now:
- 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-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
- imag-view - View entries from the imag store
- imag - The imag binary itself. The purpose of this is to be able to call
imag viewinstead of
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.
Well, what’s coming for the next release? The 0.3.0 milestone already exists and there are a lot of things already registered in it.
When will I be there? Well, my initial goal was to release 0.2.0 before 01-01-2017, so I clearly managed to get it out in time. I also announced that I want to do 3-month release cycles, so the next release would be due by March 31, 2017. I will keep that goal as I’m really not sure how fast I will be. Maybe we can release 0.3.0 early, but as normal in open source: The next version will be there if its ready.
I hope to land a
imag-mail module in the next few weeks, so one can start
tracking email with imag.
I also hope to land
imag-annotation to be able to annotate other entries
imag mv will also be a thing that should go into 0.3.0 as well as more
And, of course, there will be a ton of enhancements to the libraries in imag.
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 crates.io, so why not). Just keep in mind that interfaces will change and things will break and bugs will happen. We are 0.2.0 here, not 1.x.y. Keep that in mind.
For the curious, non-developers: imag consists not of one command/binary but of
Each of those has a library accociated with it:
imag-diary project is only a commandline interface to
There are some general purpose libraries in the imag codebase - for example
libimagerror which are used by all other crates for a certain thing, error
handling in this case.
These libraries can be used independendently of imag itself.
As said above, I do not guarantee anything in regard of API stability
or such, so one could use them outside of imag, but I do not encourage it.
Well, I won’t change my day-to-day rhythm when developing imag. As said, the 0.2.0 release was done to get some attention on imag and to people notice that some things might work, to play around and to report issues. 0.3.0 will be the same kind of release, but with more features. I don’t know when I will be confident and say “Yep, one could now start to actually use this”, but I guess that it won’t be 0.5.0 or 0.6.0 (which are not even planned by now). Maybe it will be 0.10.0 - who knows.
It also really depends on whether there will be (long term) contributors or not. If some people start working on imag more frequently and I can get a small community build up around the project, imag might be in a usable state “pretty soon” (read: within 2017 or 2018).
If not, … I don’t know. It’s really that kind of project that runs forever. Does that bother me? A bit, … but working on imag is fun and a pretty nice hobby… so I don’t care that much.
That beeing 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