feat: allow Helm APIVersions Capabilities

[charlesthomas]

previous work enabled Helm KubeVersion. this enables APIVersions as well

additionally instead of continuing to drop HelmVersions Capabilites silently, warn the user and provide the value that will be used

[mkmik]

thanks

[charlesthomas]

@mkmik looks like there hasn't been a new version cut in a while. any idea when that will happen?

looks like most of the automation is in place to potentially do that automatically on merge to main. is there a reason that hasn't been enabled? would the maintainers be interested in a PR to enable it?

[mkmik]

I'm not sure I understand correctly.

Are you suggesting to enable the automation to release a new point release automatically for every new commit?

[mkmik]

(in the meantime I filed #419)

[charlesthomas]

I'm not sure I understand correctly.

Are you suggesting to enable the automation to release a new point release automatically for every new commit?

potentially, but not necessarily

i was imagining using svu, which can decide based on the commit message what the next version should be, and if there should be a new version at all.

by default the version stays the same unless you prefix the commit message with feat: for a minor bump and fix: for a patch bump

more details here

[mkmik]

Does it work well when commits get merged at arbitrary orders based on the merge queue / kodiak?

We also get tons of automated dependency updates (thanks to renovatebot), which I guess don't matter much but it's still worth to take that into account when deciding whether using such tool is safe.

That said, I generally like the idea. One of the reasons for putting new half-assed features behind a --alpha feature flag is to prevent blocking releases until some work has completed, so it should be fairly straightforward to enable such a tool.

I'd welcome a PR to help set this up!

[charlesthomas]

Does it work well when commits get merged at arbitrary orders based on the merge queue / kodiak?

We also get tons of automated dependency updates (thanks to renovatebot), which I guess don't matter much but it's still worth to take that into account when deciding whether using such tool is safe.

That said, I generally like the idea. One of the reasons for putting new half-assed features behind a --alpha feature flag is to prevent blocking releases until some work has completed, so it should be fairly straightforward to enable such a tool.

I'd welcome a PR to help set this up!

i have always used the --force-patch-increment option so i don't actually know for sure what it will do.

my expectation is that unless those things explicitly use the feat: or fix: tags it should just do nothing.

in the case of mulitple commits since the last tag, it always chooses the biggest version bump. EG if you merge a branch that is all chore: there's no change. 1 chore: and 1 fix: would be a minor, 8 chore:, 2 fix:, and 1 feat: is minor, etc

what i can do in the PR is comment out the code that would actually push a tag, so that it just reports the current version and what it thinks the next version should be. then you can just let it run for a while and observe it