docs: add automated changelog generation

[ghost]

🚨 I don't have much experience releasing JavaScript/npm stuff so I might be missing some best practices here.

---

Adds npm scripts to generate a changelog template after bumping the version:

• npm run changelog

This does:

• Prefill the changelog with the changes from the current version down to the last version (based on the current version in package.json).

We can then manually edit the changelog, commit and PR it.

We then still need to manually tag the release on master after merging the "prepare" PR. Depending on how our release process evolves we can of course also automate these steps in the future even more. For example it would be nice to automatically tag a release and create a GitHub release (based on the changelog) using GitHub actions.

Changelog

We already started using conventional commits for our commit messages when we squash a PR. That make sit easy to prefill the changelog with these messages to get something that's already human readable and adheres to the keep-a-changelog format.

I've set it up so that all commits of types feat, update, remove, fix, security get included in the changelog by default. This is just what came to my mind based on keep-a-changelog. Let me know if we should include/remove things.

I left the changelog uncommited on purpose so that we can manually go over it and adapt it as needed (remove/add things, reformulate, etc.)

Example

The following is how the automatically generated changelog for v0.0.3 would look like. Not perfect but with a few manual edits and deletions I think it'll be quite nice—and thanks to the auto-generation much much less work than collecting and linking all that info manually.

0.0.3 (2022-02-16)

Added

• adapt favicon color based on system theme (#39) (5f1d6e9)
• add connection indicator to footer (#55) (6470ab4)
• add privacy levels (#51) (7546ca7)
• add sat symbol & update balance UI (#11) (4351d13)
• add settings screen (#26) (867fff3)
• add theming support (#10) (d7268aa)
• developer docs (#37) (d843770)
• display basic yield generator report (#73) (b37de70)
• do not autocomplete password when creating wallet (#38) (0db76d9)
• fancy toggle switch (#63) (ed8aa4b)
• hide sensitive info on wallet create (#77) (174726b)
• improve wording in settings (#71) (cd2f0bf)
• rename accounts to privacy levels (#79) (3b882f4)
• setup code formatting (#21) (08232d7)
• style navbar (#29) (699e951)
• update create wallet flow (#62) (8ed27ae)
• update earn page (#82) (7d62a38)
• update receive page (#85) (756d8e8)
• update send page (#76) (0d71915)
• update wallets page (#64) (f900344)

Fixed

• add integration pr links to readme (#95) (20aa39b)
• brighten loading indicator in dark theme (#53) (693fdf1)
• change navbar collapse to offcanvas (#44) (97ae86b)
• condition check during wallet confirmation (#93) (9d0baf1)
• display amount of addresses correctly (#49) (216dc2b)
• display info text on send page if service is running (#86) (4070d70)
• extract error message of text/html response (#84) (ffa1afa)
• fix and dry up font featues (#98) (ac762c5)
• hidden balance icon alignment and size (#52) (8bb8b7b)
• initialize local storage with default values (#33) (712b289)
• Invalid DOM property 'class' in App (d2173cd)
• navbar padding (#48) (1a04910)
• navigate to root on unmapped path (#89) (6f0f515)
• prevent dom validation warning (#5) (88e2ed6)
• show loading indicator until all data is fetched (#3) (37d882f)
• update sat symbol (#36) (765c9d7)
• use sprite instead of plain logo (215e2fa)

[dennisreimann]

Looks good from first glance. Just fyi there is also the npm version command that includes the tagging.

[ghost]

Just fyi there is also the npm version command that includes the tagging.

Nice, thanks! I think I'd even prefer that. The library I use for the changelog wants to bump the version by itself but I'd much rather stay as close to native npm tooling as possible. I'll check if I can integrate npm version somehow and let the changelog library only generate the changelog and nothing else.

[ghost]

Updated it to npm run changelog. Doesn't bump the version now. It now takes the version from package.json and updates the changelog with all changes between that version and the last tag. That way we can keep using npm tooling for bumping etc.

I'd still opt for automating as much as possible. But it's probably better to have individual building blocks that we can then automate vs. doing it all in one go.

[theborakompanioni]

Nice! 💪

Only nit: package-lock.json has been checked in with v0.0.3 - causing untracked git changes on npm install.

[dergigi]

Great stuff! Looks good to me ✅

I tested it by bumping the version to 0.0.3, everything worked as expected. I'd say let's merge this and update the changelog in one go for all past versions once we do the release tag?

One more thing that just came to mind: any thoughts on rc tags for release candidates? Not that it's required now, just wondering if some of you have any strong opinions or insights in that regard.

[ghost]

Only nit: package-lock.json has been checked in with v0.0.3 - causing untracked git changes on npm install.

Fixed! That was from testing and I probably forgot to revert it.

[ghost]

One more thing that just came to mind: any thoughts on rc tags for release candidates? Not that it's required now, just wondering if some of you have any strong opinions or insights in that regard.

No strong opinions. We could also think about adding a -alpha or something like this now that I think about it.

[ghost]

update the changelog in one go for all past versions

We'll need to do that manually since we didn't use conventional commits back then—so not much will show up in the autogenerated changelog. I can take care of that in a separate PR though.

As for the general release process, since master is a protected branch, we won't be able to bump and tag in one go (assuming we want the release tag on master which probably makes sense I would say). We'd have to do somethign like this:

1. Prepare release: Bump and update changelog.
2. PR changes to master
3. Tag release on master

Thoughts? If ok with everyone I can add npm scripts for that to make the process easier and documented in a way.

[ghost]

update the changelog in one go for all past versions

We'll need to do that manually since we didn't use conventional commits back then—so not much will show up in the autogenerated changelog. I can take care of that in a separate PR though.

As for the general release process, since master is a protected branch, we won't be able to bump and tag in one go (assuming we want the release tag on master which probably makes sense I would say). We'd have to do somethign like this:

1. Prepare release: Bump and update changelog.

2. PR changes to master

3. Tag release on master

Thoughts? If ok with everyone I can add npm scripts for that to make the process easier and documented in a way.

Moving this discussion to an issue. ☝️ #105 Would love to hear everyone's thoughts!