Flyte enables production-grade orchestration for machine learning workflows and data processing created to accelerate local workflows to production.

Flyte

Hi team, I noticed that flyte 1.10.0 and 1.10.1 helm charts still refer to the docker version of 1.9.37 of it’s components. Does this mean noone built the docker images for the flyte components for 1.10.x ? Also is 1.10.x version the same as 1.9.37 and can we use it instead ?

<https://github.com/flyteorg/flyte/pull/4213/files#diff-638f077159e277b61cb799423fd14a2c496b05799d05fb998823984bf979344a>

you can see from this job <https://github.com/flyteorg/flyte/actions/runs/6592273299/job/17913579401> that these two tags are the same
```<http://ghcr.io/flyteorg/flyteadmin:v1.9.37|ghcr.io/flyteorg/flyteadmin:v1.9.37>```
and `<http://ghcr.io/flyteorg/flyteadmin:6f02b4c164f0f229628d02ef2e63fbe273847fd6|ghcr.io/flyteorg/flyteadmin:6f02b4c164f0f229628d02ef2e63fbe273847fd6>`

i think we might play around with tagging a bit more.  there’s a bit of a chicken and egg problem not that everything’s in the same repo.  (ie the commit that updates the values can’t be same commit as the release itself)  but that’s not necessarily true if we don’t reference actual git shas anywhere (i don’t know if we do)

ok, I raised this cause it seemed to me a bit strange that a 1.10 release references 1.9.x artefacts that’s all. Maybe before a new major release, there should be a pre-release commit to tag the docker images and then the final release commit that updates the references in the chart.

moreover flyteconsole is tagged with 1.10.x release tag

<@U0265RTUJ5B> whenever you get a chance…

Yeah, we're aware of that. As <@UNR3C6Y4T> pointed out, we're still playing around with this, but if you take a look at the official helm charts, they all use the correct tag, e.g. <https://artifacthub.io/packages/helm/flyte/flyte-core>.

This discrepancy is annoying and we'll fix it, but from the perspective of consumers of the official helm charts the version is correct.