Summary
The user is inquiring about the significant version jumps in the Airbyte Helm chart, from 0.67.17 to 0.78.4, then to 0.101.2, and further to 0.220.1, leading up to the current version 0.399.0.
Question
what is going on with the airbyte helm chart versions? It jumps from 0.67.17 to 0.78.4, and then a couple versions later it’s 0.101.2, and a few versions later, 0.220.1. The current version is 0.399.0!
This topic has been created from a Slack thread to give it more visibility.
It will be on Read-Only mode here. Click here if you want
to access the original thread.
Join the conversation on Slack
["airbyte-helm-chart", "version-jump", "platform"]
I just upgraded to 0.390.0 like 7 hours ago T_T
do you happen to know where it is maintained? I wanted to check the changelog :3
a changelog.md would be nice
I believe this is likely from when they moved to Cloud being deployed off the same basic charts, but they use CI/CD there, so anything affect the charts is going to version much more quickly than the corresponding app version releases
Very likely that this is done in an automated manner in their tooling, as is common with a lot of open source projects
this is probably as close to a granular changelog as you’ll get 
https://github.com/airbytehq/airbyte-platform/commits/main/
I’m guessing that the gaps in versioning may have to do with unmerged branches or things that only apply to cloud and aren’t pushed back to the main repo, but all of this is just conjecture
at the end of the day the numbers don’t matter, and really all you’re going to tend to care about is the app version unless you’re troubleshooting a specific deployment issue related to the charts
It would be nice if they could at least follow semver. There are breaking changes in values.yaml somewhere between 0.67 and 0.399
yeah, they pretty much completely rebuilt a lot in there somewhere. unified external database and storage configs come to mind
yea, I found out the version doesnt matter really much but everytime I’m afraid to upgrade haha
ran into troubles all of the times because of the global.storage thats not quite documented
maybe they’re still not set onto the configuration yet
I’m glad they are using the same charts on their own deployment. That means it will get strong support.
they just updated all the deployment docs, so these should be accurate:
https://docs.airbyte.com/deploying-airbyte/integrations/storage
it looks like they haven’t redirected the old docs page though, so if you’re still looking at the “Deploy Airbyte on Kubernetes using Helm” page, run away—those are hopelessly out of date
niceee, I missed this
was trying to check on the helm chart docs but they’re still not there
hm, seems worth putting a docs bug in for that one. when in doubt though, read the code :rolling_on_the_floor_laughing:
https://github.com/search?q=repo%3Aairbytehq%2Fairbyte-platform%20"global.storage"&type=code
I’m guessing you’ll probably find similar for the database config too. in the latest versions you don’t have to set externalDatabase at all anymore, it’s all under global.database 
Looking at the source for all the charts, externalDatabase isn’t even read anywhere anymore
for a while you had to set both. and it made me sad 
yeah, got a grip with this one too…
Im authenticating to db with cloud-sql-proxy and --auto-iam-authn workload identity, so I don’t specify password
It just doesnt let me as before (I think because one of the new pods of the new architecture - https://airbyte.com/blog/introducing-workloads-how-airbyte-1-0-orchestrates-data-movement-jobs doesnt start with empty DATABASE_PASSWORD)
but fine, just bitter of a sleepless night today HAHA