Support for user specified server/sdk versions

[datoslabs]

Support for user specified server/sdk versions

[jlegrone]

You can install multiple different Temporalite versions (as more are released). However Temporalite/Temporal server versions are tightly coupled since Temporalite uses the server project as a library, and I don't think this is likely to change any time soon.

You can already run any version of any language SDK against Temporalite, though this capability is of course limited if you're using the temporaltest package because that means Temporalite (and transitively Temporal server) is also consumed as a library in your tests. However we may add support for lazily installing different Temporal server versions as part of SDK specific test helpers, eg. TestWorkflowEnvironment in the TypeScript SDK. Does this latter approach make sense for your use case @datoslabs?

[datoslabs]

Yes, I think that would work. Also, it would help to align Temporalite version with Temporal server version numbers to make it easier for developers to install the correct version of Temporalite for their target production environment. As a side question, I have not come across documentation on the language-specific SDK version support by Temporal server version; do you know where I can find this info?

[cretz]

Yes, I think that would work. Also, it would help to align Temporalite version with Temporal server version numbers to make it easier for developers to install the correct version of Temporalite for their target production environment.

We may be able to do this in the downloading APIs, but in general this is difficult to rely on. Temporal server release cadence may not match Temporalite. We may be able to provide a table somewhere that shows which versions are which Temporalite versions, but relying on older Temporalite which may have had since-fixed bugs is a bit concerning.

Why can't you use the latest Temporalite? Newer Temporal is meant to be backwards compatible with older Temporal servers. Temporalite isn't suggested for production, and if you're counting on nuanced differences between your production server version and Temporalite in your tests, who knows what differences your missing with a different database, different configuration, etc. If you're concerned you may use newer features in tests than you do in production, those same concerns may exist with the environment/configuration too.

I would strongly suggest that if older versions are important to you because your test relies on such specific detail, you use local docker compose.

I have not come across documentation on the language-specific SDK version support by Temporal server version; do you know where I can find this info?

These are brand new. https://typescript.temporal.io/api/classes/testing.TestWorkflowEnvironment#createlocal in TypeScript and https://python.temporal.io/temporalio.testing.workflowenvironment#start_local in Python will lazily download Temporalite and start it.

[datoslabs]

Valid concerns regarding the challenges associated with aligning Temporalite and Temporal server release cadence; a table mapping Temporalite version and Temporal server version would be a helpful alternative.

Why can't you use the latest Temporalite?

Since I don't yet have a production deployment, I have already refreshed my SDK and server to use the latest. I am looking at down the road when I have a production environment that is running an earlier version what would be the best approach for my developers to run their tests locally. Temporalite, IMHO, is an invaluable solution for developers to test their code locally; among other benefits, it has a far smaller memory footprint (compared to local dev cluster via docker-compose) and does not require WSL (if running on Windows). It would greatly improve developers' experience if there is a way for devop teams to standardize Temporalite "configuration" to match various environments so that developers have one less thing to worry about.

I will give TestWorkflowEnvironment a try; is there a future roadmap to offer IDE plugins so developers can deploy and run their workflow test harness right from their IDE?

[cretz]

a table mapping Temporalite version and Temporal server version would be a helpful alternative.

👍 In the meantime, you can look at the go.mod file in tags.

I am looking at down the road when I have a production environment that is running an earlier version what would be the best approach for my developers to run their tests locally.

I think you'll find this isn't a concern due to our compatibility stance for the server. All of your devs can use the latest Temporalite but I would recommend running something matching your production system more closely (version, database, ElasticSearch, etc) in CI for more than just version reasons.

is there a future roadmap to offer IDE plugins so developers can deploy and run their workflow test harness right from their IDE?

While there are ideas for IDE plugins for certain debug items, there is not really a plan to make a plugin for a simple, single-line command. If necessary, we can show how to start a binary from a button in your favorite IDE or, once Temporalite is containerized, show how to run code in a container e.g. in vscode.

[jlegrone]

There are some good ideas discussed here. For now we don't have plans to support dynamically pulling in specific versions of Temporal server via Temporalite, so I'm going to close this issue.

Going forward however, I hope to at least make the question of "what Temporal server version is in a Temporalite release?" easier to answer by including this information in the release notes published here: https://github.com/temporalio/temporalite/releases.

You can also find out which version of Temporal server is embedded in an existing temporalite binary by running temporalite --version.