Formalize a changelog process

[esoterra]

We should decide on a workflow for generating changelogs as the need for a more robust release system grows.

Since wit-bindgen main is composed of commits made from PR descriptions and most changelog tools use commit messages, the simplest option will be to enforce some format on all PR titles + descriptions and then use a git-based automated tool in a GitHub Action.

Here are some options I've found, feel free to suggest others.

• Conventional Commits (Documentation, GitHub Action, Example)

• gitchangelong (Documentation, Example)

• auto-changelog (Documentation, GitHub Action, Example)

[willemneal]

I second this. This is especially useful when making breaking changes. I know this project is still waiting for the upstream componen model to stabilize, but in the meantime using this will allow current users to use without fear of breaking changes.

I am also an advocate for publishing the project as is and using the same git conventions to auto publish as development continues.

[alexcrichton]

Personally I'm not too enamored with automatic changelog generators so I don't have an opinion on which myself to use. That being said I'm not opposed if others would like to use one and I think it'd be best to pick one which isn't too much overhead to follow for contributors.

[esoterra]

We could also do something simpler and more manual like the keep a changelog guidelines if people prefer.

[ricochet]

Conventional commit's core benefit is that it enables auto-versioning of releases (feats bump minor, breaking major unless major is v0). The added benefit is that it can be used to generate a changelog.

The answer to how to manage a changelog is likely wrapped in other questions about how to create releases.

[alexcrichton]

I'm going to close this as this repository isn't quite the central location for everything *.wit related it used to be. With the current refactoring big changes could come in from a number of places and as a result I don't think that necessarily keeping a formalized changelog in just this repository is going to improve things much.

What does need to happen, however, is overall documentation about working with components, *.wit, hosts, guests, etc. I don't think that's best done through a changelog here in this repository and I don't think it's necessarily too actionable to have an issue open for it as well. I expect that this sort of documentation and tutorial will grow over time as the component model stabilizes and finalizes. As a result I'm going to close this now, but this can be revisited once this repository has a more clear process of releasing things and what it's going to contain long-term.