At the moment, I'm handling changelog updates and versioning myself. I manually update the version in package.json, but in fact npm and Yarn have a way to handle this automatically. They each have a command,
npm version and
yarn version I think, that will bump the version number in package.json and commit. That'd be great! Except... I've also got a CHANGELOG.md I'd also like to see updated.
As I commit new changes to a project, they are added beneath a
## [Unreleased] header. When I ultimately version a project, I add a header beneath that like the following:
## [0.9.2] - 2020-07-28. I also have to add a line to that file's footer that looks like this:
[0.9.2]: https://github.com/thombruce/thombruce.com/releases/tag/v0.9.1...v0.9.2. And I have to modify the line above that to indicate that unreleased changes are now those after v0.9.2. I manually update the version in package.json at the same time, commit both updates with a commit titled
v0.9.2 and create a tag with the same title.
It's a tedious task that, so far as my live website is concerned, doesn't actually matter. The live site always reflects the master branch, regardless of versioning. But it's still nice to have versioning, particularly with tags and a changelog, to record a project's history.
Thing is, because it doesn't actually matter for the live site, I should just automate it.
My automated steps should:
- Update the version in package.json
- Insert a header below the Unreleased header in CHANGELOG.md with the new version number
- Update the CHANGELOG.md footer with a modified unreleased line and a new line for the new version
- Commit these changes with a commit message like "v0.1.2"
- Tag this commit with the same message
- Push to GitHub (ideally skip CI)
- Update git submodules, commit these changes and push (the CI build will happen here)
Why would 7 happen last? Surely that means another unversioned, untagged change? Yeah, that it does. But it's the recursive submodule problem again - I want my site to publish the latest version number and changelog, and what my site publishes is determined by the submodule. Therefore, this has to be done independent of versioning.
Again, I've discussed this before, but there's definitely a case to be made for removing the contents of the
content directory from the master branch entirely. Their contents are a pollutant that don't exactly hold any bearing on code developments. A discussion for a later time though.
I'm not going to introduce this nightly build concept just yet but the above is, in principle, how I'll go about it when I do. ... I'm still mulling it over.