feat!: bump hedgedoc version to 1.10.7, move to cloudpirates chart

[gianklug]

Description

Issues

Checklist

• This PR contains a description of the changes I'm making
• I updated the version in Chart.yaml
• I updated the changelog with an artifacthub.io/changes annotation in Chart.yaml, check the example in the documentation.
• I updated applicable README.md files using pre-commit run
• I documented any high-level concepts I'm introducing in docs/
• CI is currently green and this is ready for review
• I am ready to test changes after they are applied and released

[hairmare]

It looks like there are some outdated references to bitnami postgresql:

Failed to pull image "docker.io/bitnami/postgresql:15.2.0-debian-11-r2": rpc error: code = NotFound desc = failed to pull and unpack image "docker.io/bitnami/postgresql:15.2.0-debian-11-r2": failed to resolve reference "docker.io/bitnami/postgresql:15.2.0-debian-11-r2": docker.io/bitnami/postgresql:15.2.0-debian-11-r2: not found

These will most likely need to be addressed before we can get this merged.

[gianklug]

@hairmare what's the way to go here? We originally started shipping this with a bitnami DB because of the philosophy that every chart should install out of the box (and during linting).

Pivoting away from Bitnami for a minor release would probably be too breaking.

[hairmare]

let's ask @c0rydoras how he solved it for the timed chart 😬

[hairmare]

that said,,,,

pivoting from bitnami is ok, we might want to mention that the database isn't considered to be part of any breaking api, we recommend that people care about their database and don't manage it via the included chart. The included setup enables PoC work + CI, but it ain't your free ticket to a dba managed env.

[pree]

As mentioned earlier, even if this should not be used for production workloads it could still introduce a breaking change depending on the values used. So I would at least do a minor version bump, instead of just a patch.

[gianklug]

I thought I upped this to 1.0.0 o_O

this is 100% breaking

-> will update

[pree]

I agree that we should stick to semver and even do a major upgrade, but I'll let my colleagues some time to review this too!

IIRC the bitnami chart doesn't set the retention policy to Retain by default, so this could potentially lead to data loss if not investigated correctly on improper setup environments. But still, this is a breaking change, as it also requires changing the values due to the changed value set coming from the dependency.

The only alternative for me would be to remove the database from the dependency completely, either we offer it and handle the weight of it, or we remove it and leave it to the users to bring a DB.

[hairmare]

Sticking to semver includes being allowed to introduce breaking changes at anytime when still using 0.x. I strongly recommend sticking with 0.x for now, if someone requires a 1.x then we would need to put a bit of work into clarifying what it includes.

In this case, the included PostgreSQL should have never been considered to be part of the external API surface, so what we do with it is never a breaking change.

Maybe we should clearly mention that the included database is for CI only and not for production workloads. Maybe that isn't clear enough yet?