Language support module release cycles

[pvlugter]

It's not clear when and how language support modules are released, and which versions of the cloudstate proxy and protocol these are compatible with. Especially for the java-support and node-support modules in the main repo, which are currently released as needed.

In the long-term, we should be looking to have these modules in separate repos like other language support — with their own versions, automated releases, and docs (see #104), protocol versioning built-in (see #288), and TCK integration tests (#216).

[viktorklang]

Agreed. And we also need to rework the TCK so that the different language-supports can run them as a part of their build—ideally spitting out a summary of all the relevant meta data and which Cloudstate Statemodels they support.

[sleipnir]

I think that the only modules that are not separate today are Java and Node modules, all the others have completely independent life cycles. What I would like to do is to establish a versioning rule that respects the versioning of the protocol itself and that serves all language support. What I mean is that if the protocol (protos, operator, and proxy) are in version 0.5.0 and the development of Dart or Kotlin is ahead of that version (0.5.4) they should inform the version of the protocol in versioning (0.5.4_v0.5.0) or something like that because it is clear to the end user what to expect from the implementation.

@viktorklang
I agree about the TCK but I think the compatibility matrix can be done initially simply by documenting what each language supports in its own repository, then we automate that. We need a TCK independent from the main repository for yesterday, we cannot delay with that or we will be in the dark for much longer than we should.

[viktorklang]

@sleipnir @pvlugter Given how the TCK works I think it should be rather straightforward to create a Docker image for it and have the user run it against that Docker image passing in the right parameters to it. @pvlugter, is this something you can take the lead on? Let me know how I can help.

[pvlugter]

It looks like the TCK starts other processes or Docker containers. Does it work to have it run in a Docker container itself? Simplest given what I see currently, could be to publish the TCK and each language support has its own TCK build — simply break apart what's there currently, each support has a small sbt build for the TCK and paradox.

[pvlugter]

On versioning, I think we'll expect the cloudstate protocol, proxy, and language supports to have different rhythms — so not sure if they should be aligned on version series (like 0.5.x), although maybe they are at first.

So I'd expect that at some point the protocol becomes quite stable, the proxy keeps evolving based on features that are separate from the protocol (around how akka cluster is used, autoscaling, and so on), and the language support versions are based mainly on their user APIs and how those evolve. The proxy and language supports should be clear about which protocol versions they support — maybe that's by having aligned version series, but that could be too restrictive?

[sleipnir]

On versioning, I think we'll expect the cloudstate protocol, proxy, and language supports to have different rhythms — so not sure if they should be aligned on version series (like 0.5.x), although maybe they are at first.

So I'd expect that at some point the protocol becomes quite stable, the proxy keeps evolving based on features that are separate from the protocol (around how akka cluster is used, autoscaling, and so on), and the language support versions are based mainly on their user APIs and how those evolve. The proxy and language supports should be clear about which protocol versions they support — maybe that's by having aligned version series, but that could be too restrictive?

Ok. I agree

It looks like the TCK starts other processes or Docker containers. Does it work to have it run in a Docker container itself? Simplest given what I see currently, could be to publish the TCK and each language support has its own TCK build — simply break apart what's there currently, each support has a small sbt build for the TCK and paradox.

I can understand the argument but I don't see the need to have tck and sbt's dependence on other projects.
The question of the execution of docker commands by the current tck happens due to the way it was built and not because of the support languages. If we build a TCK image, the support languages will simply execute commands from their own build tools that do not depend on the docker (make run, dotnet run, dart run, mvn run, and etc ...) because, they would be incorporating the tck in your own build. It is enough that the TCK image accepts input arguments or environment variables for everything to work accordingly.

[pvlugter]

Sure, we can look at having a standalone TCK docker image that runs the tests and leaves it up to the support module to start everything else.

But we'll probably still require a JVM and sbt for working with paradox.

[sleipnir]

Yes and No. we can still use the docker and still pass parameters to the TCK.
Do you say paradox because of the question of separating the documentation in the language support modules?

[pvlugter]

Yes, paradox for allowing each language support module to own its docs.

[sleipnir]

It is so sbt lives :D

[marcellanz]

@viktorklang wrote:

ideally spitting out a summary of all the relevant meta data and which Cloudstate Statemodels they support.

@viktorklang, @sleipnir @pvlugter For the nigthly TCK run I currently parse the output from each TCK run for failures and succeeding tests of the TCK and take it over to a struct in JSON together with other data for each run and push it to a gist repository.
I think it would be nice the TCK would spit out its data in a structured form, at least one to be parsed in a safer way like a "JSON line". This way, we also can report which state models are supported, and then which tests for each model pass or not. We could use the same data collected, for releases of the core project and the support libraries, to have a matrix to show what state models or which features are supported. It could be the source of truth and be validated solely by the TCK, which would be a functional proof of it. wdyt?

[sleipnir]

I think we would only gain from this \0/

[viktorklang]

@marcellanz Having a structured output would be really nice—perhaps even the ability to directly generate a report.

[marcellanz]

I can take that as an action item for the TCK, as I currently learn how it works, to have the output the TCK produces beeing added a structured output of its results; or anyone who likes to have a stab at it.

technical note: to keep things simple, it might be too much to fiddle with stderr/stdout channels for that or even having an output file produced. The TCKs image output, with now #216 supporting it, through /dev/stdout could be the channel to transport that, I'd be fine to have it the last line (JSON line) be the structured output to be parsed by a caller and having "normal" output for humans above this last line)

@viktorklang regarding having a report, I though about to have the TCKs report being that structured output and for a human that runs the TCK image having a textual CLI representation of it.

Any succeeding task, like a TCK board runner, can then parse the structured output and produce whatever he likes to, like:

• a visual TCK board
• core/proxy <=> Language Support compatibility table/matrix for documentation (paradox).

We might send the textual CLI report to anyone interested or having it on a travis/CI log displayed. For "local" development, the report is just displayed for a developer to have it run locally.

So basically whenever I run a TCK image as a human, I get the results visually as CLI text and the last line is structured to be parsed by anyone interested.

Regarding a release cycle, if we release a version of the proxy, a TCK report would be the input of the compatibility matrix for what we support, for any support library covered by the TCK. For sure, user libraries documentation have to match that and we probably would not release if one of the major support libraries fail the TCK. But having that automated liberates us to having that tracked and documented manually.