Upgrading `com.datomic/client-cloud` to "0.8.105"

Recently I’ve been trying to update com.datomic/client-cloud to the latest version, from “0.8.102” → “0.8.105”, but when I do the ion-dev :push it’s telling me that datomic cloud is still running the older “0.8.102”. Both of my systems (for the app I am pushing) are running the most recent version of datomic, so I assumed it would include that latest version of client-cloud as well. Are both of the systems actually including an older client-cloud lib version? Which system is the :push operation using to determine the dependency versions
that we should be locked down to?

▶ datomic cloud list-systems
[{"name":"core-dev", "storage-cft-version":"781", "topology":"solo"},
▶ datomic system list-instances core-prod
▶ datomic system list-instances core-dev
▶ clojure -M:ion-dev '{:op :push :uname "checking-deps"}'
(cognitect.s3-libs.s3/upload "datomic-code-...96" [{:local-zip ".datomi...ng-deps.zip", :s3-zip "datom...zip"}] {:op :push, :uname "checking-deps"})
{:uname "checking-deps",
 :deploy-groups (core-dev-primary core-prod-primary),
  #:com.datomic{client-api #:mvn{:version "0.8.54"},
                client #:mvn{:version "0.8.111"},
                client-impl-shared #:mvn{:version "0.8.80"},
                client-cloud #:mvn{:version "0.8.102"}},
  "The :push operation overrode these dependencies to match versions already running in Datomic Cloud. To test locally, add these explicit deps to your deps.edn."},
 "clojure -A:ion-dev '{:op :deploy, :group <group>, :uname \"checking-deps\"}'",
 "To deploy, issue the :deploy-command, replacing <group> with a group from :deploy-groups"}

@jmshelby Thanks for catching this! You’re findings are correct, we have not released the latest client-cloud with the latest template. It’s coming on the next release! There should be no issues with this in terms of functionality.

Thanks @jaret. So when I run the :push op, if I have two or more stacks running different versions, which system does it use to calculate the dependency conflicts? Is it going to look at the oldest one?

@jmshelby I think you are possibly conflating push and deploy. Push moves the files to s3.
The CLI tool is the tool catching the deps conflicts, it does not connect to a machine to know the deps conflict. In the event you are running two stacks you will only push once to s3 and deploy twice, once for each system.

Push and deploy are system scoped so to answer your question directly it will resolve version deps conflicts per system. Because each system has it’s own s3 bucket.

Thanks @jaret , I understand the distinction between the two operations, and that :push is about building and pushing the code to the S3 location (I only run push once). Because I only need to run :push once, and there is no param to provide a system name, then it makes sense to me that the :push operation is actually “app” scoped (based on what’s specified in the ion-config.edn), and it pushes to an S3 bucket at the “app” level.

So because the :push operation is not at the system level (because I can’t provide a system name or deploy group for that operation), how does the :push operation know what the dependency conflicts are? I imagine, you’d need to know what version a system is running to know what dependencies it’s using. So in a multi-system environment (for the same app), when I run :push, (which doesn’t allow me to specify a certain system/group), which set of dependencies is it assuming is running in datomic? (since each version of a system/group could be running with different dependencies).

@jmshelby Let me discuss with the team. I think I understand exactly what you are encountering here. We have a few people out on vacation who I would like to verify my understanding with before commenting. I will update you as soon as I’ve had a chance to discuss with them. Thank you for bringing this multi-system, same application scenario to my attention.