Redo versionning

[ewjoachim]

Fixes #233

• Switch to main branch
• On each commit to main, after tests pass, (re-)tag the action as vx, vx.y and vx.y.z

When this is merged, it's probably worth doing a v3.1.0. Also, we need to change the default branch and update the existing PRs, and delete the v3 branch

At this point I have no idea how to handle minor or major versions (e.g. how to make it so when we merge a PR that warrants a version change, it's not immediately released as incremental)

[github-actions]

End-to-end public repo

[github-actions]

Coverage report

The coverage rate went from 100% to 100% ➡️
The branch rate is 100%.

None of the new lines are part of the tested code. Therefore, there is no coverage data about them.

[kieferro]

At this point I have no idea how to handle minor or major versions (e.g. how to make it so when we merge a PR that warrants a version change, it's not immediately released as incremental)

Yes, this is a point that I also noticed

We should also make sure that we set a very current tag before deleting the branch, so that the action doesn't fall back to the v3.0.0 tag for a short time because no new tag has been created yet, but also no branch exists anymore.

[kieferro]

I thought about it a bit more and somehow this versioning system doesn't feel convincing to me. We create a new tag for each commit (for which the CI is running) and I don't quite see how our workflow should work when we want to increase the major or minor version. And I'm not so convinced about pushing tags around that may be linked to official releases either.

What if we do it a bit differently and use the following system:

• After the CI runs, we delete all tags ending with -development.
• Then we take the last tag with schema v*.*.* and add a -development after it and use that as the tag for the latest commit.
• If we want to increase the major or minor version, we just tag the latest commit with the new version number

So the basic idea would be that we have a development tag that we push around so that everyone who just uses @v3 is always up to date and the "real" version tags always stay in the same place.

That might also have disadvantages that I'm not thinking of right now, but that would somehow appeal to me as a system better than moving the "real" release tags around or creating a whole lot of tags.

[ewjoachim]

Well, what I suggested is what GitHub says we should do, unless I'm mistaken:

We recommend creating releases using semantically versioned tags – for example, v1.1.3 – and keeping major (v1) and minor (v1.1) tags current to the latest appropriate commit.
source

The only change I did was adding minor tags too but I can remove that. The part where we force-push tags is their idea.

That said, we can discuss alternatives for sure!

Can you expand on the benefit from your solution compared to having people use @main? Using @vx.y.z-development in your workflow will only work until we release the next incremental which feels a bit like a pain, no ? Plus dependabot is likely to be confused and suggest to people to switch from dev to non-dev tag, though I can't say for sure.

[ewjoachim]

Here's an iteration:

• I've removed the minor tagging, so we tag the full version (vx.y.z) and the major version (vx)
• The major version is just a tag we push, but the full version is a full-fletched GitHub release with automated changelog
• Bumping minor happens automatically whenever we have a breaking indicator (conventional commit style) in a commit message since last tag (so a commit message prefixed with x!: , x being anything)
  (disclaimer: I haven't tested it yet, wanted your opinion first) (bumping major will stay an automated process)

[ewjoachim]

Another alternative could be to just say we release manually once in a while (which we haven't been doing a lot) and have our workflow repush the vX tag when we push a release. This means people on v3 will get the latest release instead of the bleeding edge, so it may take a while to figure out if there's a problem.

[ewjoachim]

I just thought of 2 other possibilities:

• we keep a 2-number version instead of a 3 number. So there's just minor and major. We do a minor tag every commit on main, major tags are handled by hand. Or:
• calver. But given we don't plan releases in advance, that might get weird.

[kieferro]

Can you expand on the benefit from your solution compared to having people use @main?

Compared to that, there is really no advantage. If we were to come up with a concept for an action that no one uses yet, I would absolutely be in favour of people who want bleeding-edge functions simply using @main, and we would keep manually publishing a release every once in a while without force pushing the tags, so that everyone else gradually gets the new functions as well.
But the problem is that pretty much all the people who use the action are already using @v3. I also thought that was the problem we were trying to solve. Namely, that everyone who uses @v3 should continue to get bleeding-edge. That was the intention behind my suggestion, that we find a way between force pushing tags and having everyone switch to @main, by effectively making @v3 an @main by always adding a tag at the most recent commit that redirects the @v3 to an @main.

[ewjoachim]

But then I'm not sure what usecase the "development" tags would help ?

[ewjoachim]

(Switched to vx.y without incremental. This eliminates the need for distinguishing incremental releases from minor ones. If we're releasing with every PR and always keeping backwards compat anyway, then there's no real difference)

[kieferro]

But then I'm not sure what usecase the "development" tags would help ?

Ah no, my mistake, I'm sorry. I made some wrong assumptions and thought that Github would have more logic for finding a specific version. Just ignore what I suggested.