Almost all issues for the 0.2.0 release of imag are done.
Here are some notes how I want to do releases before the 1.0.0 version of imag,
which, of course, is really not there yet. But I had to think about a decent
release strategy for the
0.x.y releases, so here the notes.
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 existing tools and add meta-information to these connections, so one can do data-mining on PIM data.
First, all the things I note here apply to releases before
I want to do
0.x.0 releases with a bunch of new features every 3 months or
something like this. This time range is not fixed, and releases will happen if
they are ready, but 3 month is a good first idea, in my opinion.
I won’t declare a fixed set of features for every new version, but move around
some features as I like, but I try to keep the number of changes decent.
For example, the
0.2.0 release has 49 closed and 13 open issues/prs at the
time of writing.
As I sometimes do more PRs per issue and sometimes just one PR for one issue, or
even file PRs without an existing issue in the first place, this number might
vary, but I guess about 100 issues/PRs per release should be a maximum.
What I want to do, and what I already do: I mark issues as
optionalif they are optional for the release they are attached to
soft-requiredif I would like to get them into the release but wouldn’t mind moving them to the next release
hard-requiredif they have to be in the release.
I also set a release date.
hard-required issues will get my attention first,
I try to implement them as soon as possible and get them ready. After that I
focus on soft-required things and after that on optional things.
hard-required issues might postpone a release date.
optional issues do not.
But if an issue has to move to the next release, because the release-date is
near and the issues are not solved by then, they will automatically advance.
That means, if an issue is
0.2.0, it will get
it has to move to
hard-required if it has to move to
This way, one can easily calculate when a feature will definitively be implemented in the imag codebase.
Another thing I try to do: Plan ahead a bit. At the time of writing, the
0.4.0 exist. I won’t create a
0.2.0 is done, so I try to plan ahead about two releases,
which equals about six months.
I will do
y-releases (as in
0.x.y) if I encounter a really serious bug.
But as we do not guarantee anything right now (see below), I doubt that will
All the things I wrote above are ideas how I want to do it. I will see how things work out and we’ll see whether this is doable for me or not. As I already said somewhere, I’m starting my masters degree this week and I don’t know how the workload will be. I really hope I can get things implemented as planned, but I might have to move issues to future milestones if I notice that things are not doable for me in the planned time.
Also, as we are in the
0.x.y release phase, I won’t give any guarantees on
stability and interfaces an so on.