Split helm chart version and appVersion

[viceice]

I think we should split the chart version from the renovate image version to more easily push chart updates.

We can then simply publish semver compliant versions.
Everybody can override the renovate version if required.

/cc @JamieMagee @rarkins

---

If you like or dislike this to be done please vote for this issue with 👍 of 👎 emoji

[rarkins]

Sounds fine to me

[JamieMagee]

I'm not sure it's worth it? We've had 1 pull request in the ~6 months this repo has existed.

I think it would be easier to just document how to increment the version for chart related changes.

[viceice]

@JamieMagee Ok, how do i need to change the chart version, without going out of sync with the renovate version? So we don't get a conflict on next renovate update.

[JamieMagee]

@viceice I think the version bump that you did was correct. You added a build version. This is ignored for comparisons, so chart-testing fails, the next increment of the version will include any fixes in the previous commit. These happen so often, so it's usually not a long wait.

The current PR open, which bumps the major version to 23 should fix this, but there's a docs issue that slipped in via the previous PR.

[viceice]

Can you fix that? I'm in an very early state working with helm charts

[JamieMagee]

Sure, I'll take a look tomorrow

[MindTooth]

This still a thing? Seeing the issues the past few days, having the option to update outside of Renovate releases is perhaps desirable.

[viceice]

@MindTooth sure, but we don't have a conclusion yet. So we maybe need to find more pros or cons.

[Djiit]

Hey, I'd vote for splitting the versions too. I would like to be able to follow semver for this chart and its components, not Renovate directly.
Most of the time, I'll upgrade Renovate by changing the version in the values files.
If you want to continue to upgrade this chart whenever a new Renovate version comes out, you could release PATCH versions, bumping the default Renovate version.

[JamieMagee]

What's the best way to deal with the image.tag value? Should it be unset by default, and you're required to pass in a version? Or should it be set to latest? Or should we try and roughly follow the semver of Renovate itself i.e. major versions of Renovate mean a new major version of the chart, and minor versions of Renovate still mean a minor version of the chart, but we maybe only bump the version on a weekly/monthly schedule?

If it's the last one, I should implement renovatebot/renovate#4728 😅

Also, what should we do with the existing releases? Do you want to start from scratch? Or just bump the major version?

[Djiit]

IMHO :

• continue to pin the image.tag; it should be considered as a sane default + a version that is known to be working with this chart.
• Have a look at how GitLab handles their GitLab-runner's chart: https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/master/CHANGELOG.md. I find it pretty sane; and I, as an admin, can choose to update things separately. It's not your last proposal, the one before (roughly follow the semver of Renovate itself).
• You can just bump the major version. From a user PoV, nothing breaks between the current version and the "split" version.

(edit: typos)

[viceice]

Anybody know semantic-release like tool to get this mostly automatically done. like we do for renovate itself and our gitlab-runner templates.

https://gitlab.com/renovate-bot/renovate-runner

[viceice]

this would benefit:

• Drop DinD support in favor of install mode #298

[viceice]

@viceice I think standard-version might work.

no, deprecated.

[viceice]

What's the best way to deal with the image.tag value? Should it be unset by default, and you're required to pass in a version? Or should it be set to latest? Or should we try and roughly follow the semver of Renovate itself i.e. major versions of Renovate mean a new major version of the chart, and minor versions of Renovate still mean a minor version of the chart, but we maybe only bump the version on a weekly/monthly schedule?

If it's the last one, I should implement renovatebot/renovate#4728 😅

Also, what should we do with the existing releases? Do you want to start from scratch? Or just bump the major version?

@JamieMagee I would implement like we do for our gitlab templates.

[viceice]

I'll implement semantic release the next days

[JamieMagee]

I'll implement semantic release the next days

Are you going to bump the major version? Or can helm handle version epochs?

[viceice]

I'll do a major bump. i like to make some major breaking change to simplify the chart. see dind removal issue.