I just released Calamares 3.2.1, a new-features release, and I'm trying something new for the next release. This is vaguely inspired by Paul Adams's talk about "The Art of the Pull Request". Immediately after the release, I've added several branches, one for each set of features that I want to implement for the next release. The graph displayed by QGit looks more like an octopus than ever:

Master has three immediate branches

Each branch starts with an empty commit that just says what I indend to accomplish in the branch. That way, intentions are documented inside the code repository -- portably (that is, not tied up with a Pull Request or other coding-platform feature). I can of course delete the branches later if something happens to make the branches obsolete or useless. But from here, there's a pretty clean picture of how the next release (3.2.2) is going to work:

  • Bugfixes go to master,
  • Planned feature commits go to the relevant branch,
  • Unplanned features go to new topic branches off of master.

When a planned feature is done, I will merge that branch back to master, delete the branch, and call it a day. When all of them have been merged that way, the planned features for the release are done -- and it should be ready to release.

Slightly sneaky, I can even claim "FIXES #" in the initial empty commit in the branch, and assuming I'm honest with myself about the intentions of, and effects of, the branch, when I merge to master the corresponding issues in the issue tracker will be closed automatically.

Mostly I'm curious whether working this way will help me keep the total cycle time low for the next release, while also informing others where works is "needed right now". And if it works, then in future the graph of a Calamares release will look more like an octopus, tying its feet together. Seems like a good thing for an installer framework named after squid.