Configure Semantic Release

[kalzoo]

• GitHub Actions:
  • master (to be verified)
  • dry-run off master
• Documentation
• Create and target rc branch

Note: this will need credentials to be configured before it can be expected to work on a protected branch (ie master)

[cetanu]

Nice. Do you need me to do anything to push this along?

[kalzoo]

Nice. Do you need me to do anything to push this along?

I had intended to get one more release out following the current pattern before making the switch, so it's a fresh start. That needs the optional PR to be merged, which is blocked on a bug in code generation in its pipeline.

[boukeversteegh]

Nice. Do you need me to do anything to push this along?

I had intended to get one more release out following the current pattern before making the switch, so it's a fresh start. That needs the optional PR to be merged, which is blocked on a bug in code generation in its pipeline.

Hi @kalzoo ! This is a great feature!

Over at ts-proto release bot is also used, and it's amazing how quick things move there.

To weigh in positively on this PR, I would list the following benefits.

Merged PR's are immediately released as a new version

This seems like a "nice to have" to save some effort of releasing, but it is so much more than that.

It changes the entire development and user experience.

• Benefits for users
  • Get the latest features more quickly
  • Can upgrade more incrementally. If the latest version causes issues you can try one before, and still get some new features.
  • Easier to validate a new release, as they are smaller
  • In case of breaking changes, you can update your code in smaller increments
• Benefits for all contributors
  • More accurate issue reports: users can tell us more precisely which changes broke their code
  • Contributors can work on top of the latest public release branch, rather than a non battle-tested pre-release branch
• Benefits for PR authors:
  • More satisfaction when your work is released quickly
  • When issues are reported, it's much more quickly, so you may still remember implementation details, and as you probably haven't moved on to different things yet, you may still have time to fix it.
  • Can reference the official project package more quickly instead of personal fork
• Benefits for the project
  • More motivated PR authors
  • Quicker feedback from users
  • Better feedback
  • Quicker fixes from PR authors

[MicaelJarniac]

What's the status of this? What still needs to be done?

[MicaelJarniac]

Wouldn't it be better to use another configuration file for it, like a .releaserc.yaml?
https://github.com/semantic-release/semantic-release/blob/master/docs/usage/configuration.md#configuration-file

The YAML format is already being used here anyways, by .pre-commit-config.yaml and .readthedocs.yml at least, as well as the GitHub Actions workflows, unlike JSON.

And package.json seems to be related to Node packages, which isn't the case for this project, while .releaserc.yaml is just for configuring the release automation.

[Gobot1234]

@cetanu https://github.com/compilerla/conventional-pre-commit might be a useful add here fwiw

[cetanu]

I was looking at this the other day and thought it might be good to merge this as the very first thing right after the 2.0 release, and then we can move forward from a clean slate