You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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: #498
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.
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.
The text was updated successfully, but these errors were encountered: