If there is a new version of Rocket.Chat, helm chart is not neccessarily going to have another release of the same version. Unless there is actually something that changed in the chart, no new releases will be made.
We are looking into the current mismatch confusion, and will keep eveyone updated in this thread.
Those wanting to update, simply pin a version in values.yaml like the following
image:
tag: 6.5.2
long story
Our helm chart, like most others in the wild, had its own code (templates), bugs, features, etc. Thus, entails its own release style.
For the longest time, the release pattern has looked something like the following
Rocket.Chat released a version x, helm chart released a new version x.
Much of the times, there was nothing introduced in the chart itself that contributed to a new chart version. We simply bumped the appVersion and version, and made a release.
appVersion and version always matched.
This caused problems. Such as
What happens when we need to fix something critical, that affects fresh installs?
We then either wait until a new Rocket.Chat release happens for automation to kick in and push the fix in the new version. Or, we overwrite the last existing version to push the fix. Both are not ideal.
What happens when we want to push a new feature? Same as before.
Many times, we ended up shipping fixes or features to older releases (patches of still supported major.minors)unintentionally due to the non-linear release cycle.
No real release process.
With all that in mind, we made the decision of stopping making releases like this. It is more broadly explained in this PR.
Please feel free to comment your thoughts and lets have a healthy discussion about this.
What about the confusion of the chart version being on 6.4 while rocket.chat is on 6.5?
This is unavoidable for now due to the old practice of keeping versions one-to-one matched. As of right now we are discussing how to avoid this confusion moving forward, making it clear that you can't just helm upgrade to upgrade your deployment (shouldn't anyway), but update your values file. But I don't have a clear way of achieving this yet.
My initial suggestion was to bump the version to current + 10 major. 10 is arbitrary. But adds enough distance to no longer cause any confusion. But that isn't final or I am not 100% sold on the idea either.
If anybody has any ideas, please feel free to comment down below.
Hi everyone,
tl;dr
If there is a new version of Rocket.Chat, helm chart is not neccessarily going to have another release of the same version. Unless there is actually something that changed in the chart, no new releases will be made.
We are looking into the current mismatch confusion, and will keep eveyone updated in this thread.
Those wanting to update, simply pin a version in values.yaml like the following
long story
Our helm chart, like most others in the wild, had its own code (templates), bugs, features, etc. Thus, entails its own release style.
For the longest time, the release pattern has looked something like the following
Rocket.Chat released a version x, helm chart released a new version x.
Much of the times, there was nothing introduced in the chart itself that contributed to a new chart version. We simply bumped the
appVersionandversion, and made a release.appVersionandversionalways matched.This caused problems. Such as
With all that in mind, we made the decision of stopping making releases like this. It is more broadly explained in this PR.
Please feel free to comment your thoughts and lets have a healthy discussion about this.
What about the confusion of the chart version being on 6.4 while rocket.chat is on 6.5?
This is unavoidable for now due to the old practice of keeping versions one-to-one matched. As of right now we are discussing how to avoid this confusion moving forward, making it clear that you can't just helm upgrade to upgrade your deployment (shouldn't anyway), but update your values file. But I don't have a clear way of achieving this yet.
My initial suggestion was to bump the version to current + 10 major. 10 is arbitrary. But adds enough distance to no longer cause any confusion. But that isn't final or I am not 100% sold on the idea either.
If anybody has any ideas, please feel free to comment down below.
Hope this message helps somewhat. Stay safe.