changelog

You fixed all the bugs, closed some security holes and documented new features in your project. In other words – you did a great job and the next release is ready for the roll-out. But you’re not done just yet! No? What else? You have to update the changelog file, bump the version in the respective package.json and create a git tag first. Hm, many steps, right? No more! changelog (GitHub: defunctzombie/changelog, License: MIT) by Roman Shtylman is here to save you.

 

Personally I’m not just a huge fan of the concept behind Readme Driven Development but also of planning releases in a changelog file. If this is your workflow as well, you will benefit from changelog – you don’t have to adjust your changelog when releasing a new version by hand. It’s there, anyways, as described above.

The release workflow consists of many separate tasks which don’t have to be executed manually. They can be handled by changelog. Let’s take a look:

1
npm install defunctzombie/changelog

Initialization

If you starting a new project you will want to create a new changelog. Execute:

1
changelog --init

This will create an empty HISTORY.md file for you which has the following structure:

1
2
3
# UNRELEASED
  * initial

The UNRELEASED section is for all your changes you made or will make in the version you are working on. Look at this as a personal project blog where you keep track of every unreleased change. No more external todo applications or what have you. Everything is in the context you are working in – your project.

Release

Let’s say your product is ready for prime time and you want to release the 1.0.0 version (OMG!):

1
changelog --release 1.0.0

This will will trigger changelog to perform the following steps:

  1. Convert the first UNRELEASED section to # 1.0.0 (YYYY-MM-DD)
  2. Change the version property in your package.json accordingly.
  3. Execute a git commit -m "v1.0.0"
  4. Execute a git tag "v1.0.0"

Keep on working…

Every project which does not have a roadmap with future changes is a dead project, right? I hope that the next release is always just around the corner! Next, you should start a new UNRELEASED section by executing the following and keep on working 🙂

1
changelog --increment

Closing thoughts

There might be other tools like changelog out there but this one fits my personal workflow very well and who knows, maybe yours too. Whatever tools you are using for the release management, I can not emphasize enough how important it is to write a changelog file. Not just for you as a project maintainer but also for communicating to the people who are using your product. Roman Shtylman helps with changelog to manifest this notion of centering the versioning workflow around the changelog. Thanks!

Post navigation

joi

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *