Self-hosting versioning

[n1ru4l]

We should follow the following release format for docker images, inspired by minio https://hub.docker.com/r/minio/minio/tags

RELEASE.2023-09-30T07-02-29Z

Every release should have a corresponding release changelog on docs.graphql-hive.com/changelog-self-hosted/<release-tag>.
The page will contain all the necessary information for upgrading to this version from the last version.

Releases are made from deployed versions that we have already tested in production.

[n1ru4l]

We also need to think about how we can communicate hive/cli <-> hive self-hosted version compatibility. Maybe we could create a specific tag/dist on npm that is the corresponding self-hosted version.

[Elyytscha]

i dont think minio versioning is state of the art, sane tagging should look like this:

when graphql hive version 1.4.3 (semver) is built, push the following images:

docs.graphql-hive.com/hive-server:1
docs.graphql-hive.com/hive-server:1.4
docs.graphql-hive.com/hive-server:1.4.3
docs.graphql-hive.com/hive-server:latest
docs.graphql-hive.com/hive-server:stable

https://semver.org/lang/de/

the version should be automatically determined based on the commit messages since the last released version (fix, feat, breaking change)
https://www.conventionalcommits.org/en/v1.0.0/

with conventional commits you can even auto generate your changelogs based on types (feat, fix, perf, test, etc)
https://mokkapps.de/blog/how-to-automatically-generate-a-helpful-changelog-from-your-git-commit-messages

[Elyytscha]

i mean because you downvoted, i just wanted to highlight whats my issue with the minio versioning.

devops/sre/platform engineers like to upgrade their systems automated, if they can rely on semantic versioning, they can ensure that they dont ship unwanted major/breaking change upgrades automated, so basically they can choose if they are upgrading on patchlevel, feature level or even major/breaking change level, when the application is known for handling major upgrades automated without problems.

if the versioning is simply RELEASE.2023-09-30T07-02-29Z

we have absolutely no idea if we can ship this release automated into production, we have to read the changelogs first.

[platzhersh]

I second @Elyytscha 's input.

We currently fixed the versions for our self-hosting and we are not really looking forward to the first time we will update to newer images, since we won't really know what all the incoming changes will be without going through all the commits since the version we currently have deployed.

For our own projects we are also following semver versioning based on conventional commits.

[Elyytscha]

Second @Elyytscha 's input.

We currently fixed the versions for our self-hosting and we are not really looking forward to the first time we will update to newer images, since we won't really know what all the incoming changes will be without going through all the commits since the version we currently have deployed.

For our own projects we are also following semver versioning based on conventional commits.

I mean that should be the job of cicd and conventional commits(enforce conventional commits, auto generate changelogs tags and releases and then build the images with the spit out tags), thats nothing someone has to do by hand

[kamilkisiela]

As of today, we can offer precise versions

ghcr.io/graphql-hive/server:1.2.3

You can read about it here: https://the-guild.dev/graphql/hive/product-updates/2024-10-29-versioning-for-self-hosters

---

We don't support major or minor version matching labels. I hope we will some day, but it's low priority at the moment.

ghcr.io/graphql-hive/server:1
ghcr.io/graphql-hive/server:1.2