search

nextcloud / helm

A community maintained helm chart for deploying Nextcloud on Kubernetes.
GNU Affero General Public License v3.0
295 stars 258 forks source link

Feature: align chart versioning with nextcloud release version #499

Open pfaelzerchen opened 6 months ago

pfaelzerchen commented 6 months ago

Description of the change

I am currently starting to set up Nextcloud based on this helm chart. I recognized that from version 4.5.8 to 4.5.9 of the chart, it switched from Nextcloud 27.1.4 to 28.0.0, which is a breaking change. From my experience, some apps need a while to adapt to new releases. Therefore, I am a more conservative upgrade, staying on the stable-tag of the AiO-Container.

Wouldn't it be more clear to systematically align the charts version with the semantic of Nextcloud's version itself? So when Nextcloud is moved to a new major release, the helm chart also goes to a new major release, e.g.

4.5.8 -> 27.1.4 4.5.9 -> 27.1.5 4.6.0 -> 27.2.0 (doesn't exist, I know) 5.0.0 -> 28.0.0

Benefits

It would be clearer to the chart's user, when he has to expect possible breaking changes from a Nextcloud major release.

Possible drawbacks

No Idea.

Additional information

With a GitOps operator like ArgoCD one can leverage semantic versioning, e.g. by doing automatic patch level upgrades which are usually rather safe to do. But if the chart installs a new major release on a patch level basis, this would be rather dangerous.

provokateurin commented 6 months ago

I don't think it is really considered a breaking change under semver, but I agree that it would make things clearer. Maybe the idea at the end of the issue I just opened could also help with removing this problem: https://github.com/nextcloud/helm/issues/498

pfaelzerchen commented 6 months ago

I indeed thought about going the way described in the issue. But it is good to know that the chart is version agnostic to nextcloud. It is probably not a breaking change to the chart, but the effect it has on the deployment is definitely from my point of view.

By the way, within the chart's dependencies you also rely on bitnami not doing major version changes on redis et. al within a chart's patch level change.