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 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:
- Convert the first
UNRELEASEDsection to# 1.0.0 (YYYY-MM-DD) - Change the
versionproperty in your package.json accordingly. - Execute a
git commit -m "v1.0.0" - 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!
