Proper release process

[bo0tzz]

Currently the chart is built and released whenever a new chartVersion is pushed to main. Depending on the options out there, it would be nice to make this a bit more deliberate to increase the control over when new versions are published.

Currently releases do not include any changelogs. This should be fixed so that both the github releases and the artifacthub page properly display a changelog, and ideally so that these changelogs also show up in PRs generated by tools like Renovate.

[hiteshnayak305]

i will try change log generators for CHANGELOG.md and artifacthub annotations. for now we need to update contribution guide to use conventional commit messages.

[kriegalex]

The default chart also fails to pass a proper CD/CI pipeline using the default values, because existingClaim is mandatory.

In the case of Github Actions, you can easily spawn a KIND cluster to test a helm chart, but I'm not sure if it is easy to create a PVC in the github actions workflow. Even if it is possible, in my opinion, it should work with the default values out of the box, meaning it should create a default pvc when no existingClaim is provided. Maybe I'm wrong.

This would qualify as proper release process, as now you can accept more easily changes from outsiders knowing that the default values at least still work.

[benmichael]

The helm version is now so far behind that my android clients, which auto updated (both from the play store on my wife's phone and from f-droid on my phone), are now so far ahead of my server that they are no longer compatible. I can no longer see my library on my phone, and the phone will not sync my photos. This causes major loss of wife approval for the app, which is the biggest issue.

[bo0tzz]

@benmichael #68 - you should be setting the Immich version in your own values.yaml

[especially-relative]

I'd hold that updating chart release process would be a good time to normalize it with other charts, or at least it would help set the stage for doing so eventually and have a default up to date tag that gets incremented when at least minor versions (and security patches) are released

At the very least it would also reduce surprise by people deploying the chart and ending up with an ancient version not even supported by the chart

[benmichael]

@benmichael #68 - you should be setting the Immich version in your own values.yaml

While I agree that this is possible, in fact this is best practices for the most part, there are two problems with it.

Firstly the default value of the chart should absolutely be at the very least up to date enough not to be incompatible with the clients.

Secondly, while best practices dictate that the user should update the version number in the chart, preferably using GitOps, I would at least want confidence that each new version has been tested with the chart, but I don't have that confidence. Updating the image version in the charts inherently carries the risk that there is some new requirement which the chart does not cover. And while it may be argued that the maintainers would update the chart in the case of a breaking change, it has already been shown that they didn't when the default version fell so far behind the client version that it did introduce a breaking change in the interaction between the server and the client.

I'm not here to cast aspersions upon people running open source projects, I know what a huge commitment and time sync it is, and I can't tell you how grateful I am for all the incredible work that goes into this project. I just don't understand why a request from a fan to, at the very least, change the default version number and hit release to ensure compatibility should be met with such criticism. I also thank you for the link to the correct issue, I hadn't seen it as it is marked as "not planned" and as such didn't show up in the issues list.

[bo0tzz]

surprise by people deploying the chart and ending up with an ancient version not even supported by the chart

The appVersion set in a particular version of the chart is definitely supported by that chart version. As for surprise, needing to set this is pretty clearly called out in the README, if people aren't reading that then it's a lost cause anyways.

Either way, this issue is not the place to be discussing that.