Beta branch betas?

[ab623]

Hey @acouvreur any reason you utilise a beta flag on the beta branch.

It seems that the beta branch sits on a. X.Y.0 release forever and you bump a "beta-z" flag at the end. Also seems like the merge from beta into main is very infrequent.

Have you considered just using a minor release when adding features and a patch, and merging back into main more often

[ab623]

Adding to this, some of your automated chores such as dependency updates should be point releases and features should be minor releases.

This will help some people like (including me) to pin to minor image updates only.

[acouvreur]

Hello @ab623!

The release cycle uses semantic versioning with pre-releases. You can check the specification here: https://semver.org/spec/v2.0.0-rc.1.html

It seems that the beta branch sits on a. X.Y.0 release forever and you bump a "beta-z" flag at the end.

This is very useful to pack release with multiple changes, which is why I'm doing it. It allow me to publish feature that are still qualifying, and early adopters can provide feedback on it.

As to why the version "sits" on a X.Y.0 release forever, you need to understand how semantic versioning works with pre-release.
See:

• https://semver.org/spec/v2.0.0-rc.1.html
• https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/pre-releases#initial-release

In short, for a given pre-release you can only bump one version member at a time. E.g.:

1. main is in version 1.7.0
2. publishing a fix on beta releases 1.7.1-beta.1
3. publishing a second fix on beta releases 1.7.1-beta.2
4. publishing a feature on beta releases 1.8.0-beta.3
5. publishing a second feature on beta releases 1.8.0-beta.4
6. publishing a breaking change on beta releases 2.0.0-beta.5

At any step, merging beta into main would release the current beta version without the -beta.x part.

Also seems like the merge from beta into main is very infrequent.

You are right, there are no scheduled released, or specific elapsed time during a qualifying release and it's official release.
I merge beta into main when I consider it stable.

Adding to this, some of your automated chores such as dependency updates should be point releases and features should be minor releases.

Everything is already covered by semantic-release and it's configuration .

I use Conventional Commits in order to describe the intent of each commit and semantic-release is able to understand the nature of my change to bump the version.

So, for dependency updates, they are already tagged as fix, which bumps the fix/point part of the version. Same goes for features with the feat keyword.

Examples:

What you're seeing is that, when working on a pre-release branch (beta), and the minor version has already been increased by a new feature, then fix versions cannot be changed because it would need an official 1.8.0 release first.

Does that make sense ?