search

kamilkisiela / graphql-hive

GraphQL Hive is a schema registry and observability
https://the-guild.dev/graphql/hive
MIT License
396 stars 87 forks source link

Self-hosting versioning #2995

Open n1ru4l opened 9 months ago

n1ru4l commented 9 months ago

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 commented 9 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 2 months ago

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 commented 2 months ago

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