changelog

@lipis and I discussed how we could notify users of new features. My suggestion was to show changelog in the help dialog.

Whatever we do, I think we should keep a user-facing changelog for excalidraw.com itself, not just the package. Meaning it should contain changes not listed in the @excalidraw/excalidraw package changelog.

Moreover, if we want to display a changelog in the UI, each change should stand on its own because unlike in the package, we release each change immediately. Thus, it doesn’t make sense to put the changes under sections because it would result in something like this:

# feature
- lalala
# fix
- lalala
# feature
- lalala
# feature
- lalala

Moreover still, since we’ll effectively need 2 separate changelogs, I don’t think maintaining (and syncing) both of them manually is feasible.

---

As such, I propose to maintain a machine-readable changelog, where:

1. Each line is one commit to master.
2. Each line is qualified with the type of the change (we now do that already by prefixing the commit message with feat: etc.) so it can be automatically parsed and sorted under respective section for the user-facing changelogs.

If we employ Enforce semantic PR title #2531, this machine readable changelog can be fully automated.

After that, we maintain two (or more) separate, user-facing changelogs. One for the web app, and one for the package.

The web-app changelog will largely be identical to the machine-readable (+ some styling changes so it displays nicely in the UI), while the package changelog will look more or less identical to how the changelog looks now (with sections).

These use-facing changelogs could be automated, as well.

[NMinhNguyen]

Having used conventional commits for changelog generation extensively at work (via Lerna) and recently having tried https://github.com/atlassian/changesets, I’d say that the Changesets flow is preferable because commit messages can’t easily be edited once they land on the main branch (you have to rewrite history causing conflicts for others), and generally speaking commit messages (or PR titles) aren’t very suitable for authoring text in my opinion. With Changesets, it’s a .md file that can be edited subsequently (or even deleted) and you can have them auto formatted by Prettier, you can preview the rendered Markdown in VS Code etc. 😃 Pretty sure you should be able to programmatically customise changelog generation to suit your needs as well.

[ad1992]

Yep, +1, better to follow an existing convention (also some users will be familiar with it) and these would be supported in the Github action out of the box afaik as well so we need not maintain separately.