Continuous deployment

[SimonAlling]

As discussed in #44, we should be able to automate releases in some way, now that we use Conventional Commits. I believe @avallete has some valuable experience on this matter, and maybe @lydell too.

Initial questions:

• How should version bumps be done in the code base? package.json should reflect the current release, shouldn't it?
• How should we do the actual npm releases? New patch release after each merged Dependabot PR – pros/cons?
• Is it practical to backport security fixes etc to older major versions? I'm currently maintaining a v1 branch alongside the master branch, but it seems to me like that will grow unwieldy pretty quickly.

[avallete]

Hi there.

Here is my 2 cents on this topic:

1. Depending of what you use to do the semantic versioning, it's not required to bump the version in the code base itself (see: here) and we may only keep a "boilerplate" version like 0.0.0-dev in the code.
2. I don't really see any downside to a full continuous release process. However, it's always possible to go for a "manual release trigger" with github actions if you want more control. Note that it's not the recommended approach though.
3. I would argue that having back-port is always a nightmare to maintain especially for small sized projects. IMO you should go for a single maintained version, if anyone want to maintain a specific version of the project and keep the dependencies up to date, you can still fork it, rollback your fork the the commit you want, and maintain this version.

[SimonAlling]

1. Depending of what you use to do the semantic versioning, it's not required to bump the version in the code base itself (see: here) and we may only keep a "boilerplate" version like 0.0.0-dev in the code.

That would certainly be neat.

2. I don't really see any downside to a full continuous release process. However, it's always possible to go for a "manual release trigger" with github actions if you want more control. Note that it's not the recommended approach though.

The one major downside I see is that if we were to add, say, three new breaking features, then we'd suddenly see a threefold major version bump and the current version would suddenly be 4.0.0. Confusing, no?

3. I would argue that having back-port is always a nightmare to maintain especially for small sized projects. IMO you should go for a single maintained version, if anyone want to maintain a specific version of the project and keep the dependencies up to date, you can still fork it, rollback your fork the the commit you want, and maintain this version.

I agree. No more backporting!