• The release artifacts seem bordeline useless - I hope nobody installs packages by downloading .whl files from github. If someone tried, dependency management would be hell. Are there any points against dropping them?
• It is nice that we make tags for beta releases, but shouldn't we make github pre-releases instead?

Github pre-releases can swamp the release list page - see https://github.com/vercel/next.js/releases. You can use the prerelease:false search filter, but still.

I don't like to pollute anything else than the package manager for prereleases, I would remove the git tags as well (I did in some repositories already, e.g. in the JS monorepos we maintain), since I can't justify adding tags to every single commit to master.

Sure, just removing the git tags is also an option. We'd lose a bit of traceability (what changed between those betas?), but if we keep releasing often, nobody will care 🙂

If every commit to master is a beta, it should be pretty clear what changed between those betas.

What I mean is, if you have 0.42.2b73 installed, how do you look up what changed between that and the current 0.42.2b91 if there are no tags?

You would check the git history, but I agree its a chore to find what commit triggered what version (since you need to go through the CI logs). For me this is not something I would optimize for, we don't want users to be on the beta releases (only if they don't want to wait for us to do a stable release).

To me, it's just adding (a lot of) noise, for a very low value, but that does not mean I don't see any value - so if you guys want to keep the git tags there, let's keep them (and we can remove later if you change your mind, heh). I would skip the GH releases, that really feels too much - they would always contain a single item only.

Clarification, it's not every commit, the chore/docs commits are ignored.

I don't see a problem with that either, we would ignore those commits in the changelog too.

I'm fine with removing the beta tags - every simplification of that workflow counts.

Can I also not upload the release artifacts? (see the argument above)

You mean completely, including for stable releases? I guess its fine too, I also don't think people use them, and we can revert this if we hear from someone who would like to do so.

Regarding the beta tags - I'm ok with both keeping/removing them, so do as you prefer.

i would like to be able to trigger major/minor/patch specifically (just like we have it in the js crawlee) instead of relying on the git messages. some feature commits are not really worth a feature release (but you want them in the changelog and its just wrong to call them fixes just because of this)

Thing is, I'm not aware of a way of doing this with git-cliff specifically. I know this is a weak excuse, but I really liked the idea of letting git-cliff bump our versions without having to search for yet another utility.

Can we open a new issue for this? In the meantime, we can always use the custom mode.

Also, kinda off topic, but some people (such as @netmilk IIRC) would tell you that attaching emotional value to version numbers is wrong and you should just follow the semantic versioning spec like a robot. Every side of the argument has its points IMO.

...it looks like poetry version could also work for us.

How is this about git cliff? You use that to generate changelog between two git tags or commit hashes I'd guess, or its not working that way? The option I am after would only let you decide the version bump manually instead of relying on the git messages.

This is how - it has a flag that outputs the new semver based on commits since the last tag. I used it because it was handy. The workflow_dispatch can also accept a custom version number, which will be used directly.

I agree with @B4nan on this.

I don't think we're in any kind of disagreement. You can already set a custom version, can't that be used to achieve the same thing you could do with a patch/minor/major toggle?

The points about marketing and fixing previous mistakes are both valid. While we're at the topic, can we not fix incorrect commit types by push-forcing to master? I'm aware there are tradeoffs, it's an honest question about which ones we picked.

You can already set a custom version, can't that be used to achieve the same thing you could do with a patch/minor/major toggle?

Yes, it can be used for the same, but is less ergonomic. It means you need to check the version you are on, instead of just releasing the next bump based on the type. You add another possibility for the user to screw it up. I want something in between, not full auto, but not full custom. We are using this for quite some time in crawlee, and it feels really nice, so I would like to see it the same way - especially because we want to port this setup to other repositories in the long run.

While we're at the topic, can we not fix incorrect commit types by push-forcing to master?

Force push to master is a big no-no, especially in open-source repositories. This can piss all the other maintainers collaborators off easily, seen that many times in nette community, as the author liked to do this a lot. You break their local versions since you change commit hashes.

There are exceptions to everything, but I can justify force pushing only for the very last commit done by yourself, within very short time window after they were pushed (lets say minutes).

Yes, it can be used for the same, but is less ergonomic. It means you need to check the version you are on, instead of just releasing the next bump based on the type. You add another possibility for the user to screw it up. I want something in between, not full auto, but not full custom. We are using this for quite some time in crawlee, and it feels really nice, so I would like to see it the same way - especially because we want to port this setup to other repositories in the long run.

Sure, I'm in favor of that, but I'd prefer to do that after this PR is merged and tested. Autogenerated changelogs and triggering releases via workflow_dispatch are enough of a milestone IMO.

Force push to master is a big no-no, especially in open-source repositories. This can piss all the other maintainers collaborators off easily, seen that many times in nette community, as the author liked to do this a lot. You break their local versions since you change commit hashes.

Haha, I remember that. I agree that the negative impact on contributors is not worth it.

Ok, I am fine merging this without it, that's fair. But I would like to see it implemented before next release.

the commit prefix is called docs: not doc:

https://www.conventionalcommits.org/en/v1.0.0/#summary

Oh, I based this on what we have in cliff.toml, in that case, it should be updated there from doc to docs.

I suspect that git-cliff only puts ^doc in the default configuration to catch both doc: and docs: so that they please everyone 😄

The newly added PR title check should prevent any errors anyway, but I can update cliff.toml too.

I agree with @B4nan on this.