Replies: 1 comment
-
|
Good point, we should hold it somewhere. e.g. nextcloud v33 was a major change (together with prometheus adjustments). On the one hand, as an administrator i like to see if it has breaking changes for me (based on semantic releases). And as an helm-chat update often a new major nextcloud version has no breaking changes, so a minor release is on the semantic-releases pattern okay. But on the other hand like you described. In the End we have to handle it transparent for everybody (and write the result down). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Would it be possible to have some kind of versioning to better align app and chart versions? Or at least to distinguish version updates that introduce major app version updates?
For example, 8.0.3 -> 8.1.0 was a major nextcloud upgrade to v32 (which could have app compatibility issues). On the other hand 8.1.0 -> 8.2.0 is just labeled as adding some labels to the pod template, which seems almost trivial.
I don't want to suggest going overboard, but it might add a lot of value if it were more obvious from version numbering when a major nextcloud update is going to be triggered. To be fair the appversion update was in the what's changed notes.
Beta Was this translation helpful? Give feedback.
All reactions